LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	"Al Viro" <viro@zeniv.linux.org.uk>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"Alexey Dobriyan" <adobriyan@gmail.com>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Pekka Enberg" <penberg@cs.helsinki.fi>,
	LKML <linux-kernel@vger.kernel.org>, "Greg KH" <greg@kroah.com>,
	"Kay Sievers" <kay.sievers@vrfy.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace
Date: Sun, 26 Oct 2008 22:08:45 +0100	[thread overview]
Message-ID: <19f34abd0810261408w61b1e2dbvb9a0e16ce5a10022@mail.gmail.com> (raw)
In-Reply-To: <m163nggvhq.fsf@frodo.ebiederm.org>

[Combined result for Eric & Viro]

On Sat, Oct 25, 2008 at 11:28 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>> On Saturday, 25 of October 2008, Vegard Nossum wrote:
>>> Hi,
>>>
>>> When I run readlink on the /proc/*/exe-file for udevd, the kernel
>>> returns some unitialized data to userspace:
>>>
>>> # strace -e trace=readlink readlink /proc/4762/exe
>>> readlink("/proc/4762/exe", "/sbin/udevd", 1025) = 30
>>>
>>> You can see it because the kernel thinks that the string is 30 bytes
>>> long, but in fact it is only 12 (including the '\0').
...

> Weird.  The dentry for "udevd" has an incorrect length.
> Is something stomping the length somewhere?
>
> What filesystem does /sbin/udevd reside on?

Ext3 on a USB flash-disk.

On Sun, Oct 26, 2008 at 1:23 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> (For the record: This didn't show up in 2.6.27-rc with the same
>> version of LTP, so it seems to be a recent regression.)
>
> Very odd.  Do you see that for any other processes?  Where does
> /sbin/udevd live on your box?  BTW, .config might be useful here...
>
> Can you reproduce that on e.g. amd64 and/or without kmemcheck?

IIRC, it did show up for other processes, but udevd was the only one
which exhibited the problem reliably.

Now, I've been trying to reproduce the problem (with exact same setup)
since I first saw it, but can't :-/ At the time that the machine
started showing the problem, it had been running LTP, scrashme, etc.
for hours, so it seems that it might have had something to do with it.
I couldn't reproduce it after rebooting.

This was my setup:
 - root filesystem (ext3) on USB flash disk
 - mounted LVM2/ext3 from harddisk on /mnt
 - bind-mounted /proc onto /mnt/proc

I noticed the problem from chroot /mnt, but it reproduced afterwards
on the outside as well. I also remember having remounted (with -o
remount) both /mnt (adding user_xattr to options) and /mnt/proc from
within the chroot (so with /mnt prefix removed). This could of course
all be unrelated since it didn't reproduce the problem, but at least
it is what I did.

Cosmic rays may have been involved. Will keep trying to reproduce.
Thanks for attention so far.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

  reply	other threads:[~2008-10-26 21:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-25 17:14 Vegard Nossum
2008-10-25 20:41 ` Rafael J. Wysocki
2008-10-25 22:28   ` Eric W. Biederman
2008-10-26 21:08     ` Vegard Nossum [this message]
2008-11-04  9:39       ` Vegard Nossum
2008-11-04 10:00         ` Alexey Dobriyan
2008-11-04 10:07           ` Alexey Dobriyan
2008-11-04 10:34             ` Alexey Dobriyan
2008-11-04 10:54           ` Eric W. Biederman
2008-11-04 15:48             ` Al Viro
2008-11-04 15:12         ` Al Viro
2008-11-06 10:04           ` Ingo Molnar
2008-11-07 19:05             ` Greg KH
2008-11-07 23:12               ` Alexey Dobriyan
2008-11-11 22:14                 ` Andrew Morton
2008-11-11 22:53                   ` Vegard Nossum
2008-12-03 17:18                   ` Greg KH
2008-12-03 20:20                     ` Andrew Morton
2008-12-07  5:44                       ` Greg KH
2008-12-07  7:04                         ` Al Viro
2008-10-26  0:23 ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19f34abd0810261408w61b1e2dbvb9a0e16ce5a10022@mail.gmail.com \
    --to=vegard.nossum@gmail.com \
    --cc=adobriyan@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=rjw@sisk.pl \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).