linux-kernel - Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 26 Oct 2008 22:08:45 +0100
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Al Viro" <viro@...iv.linux.org.uk>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Alexey Dobriyan" <adobriyan@...il.com>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>, "Greg KH" <greg@...ah.com>,
	"Kay Sievers" <kay.sievers@...y.org>, linux-fsdevel@...r.kernel.org
Subject: Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace

[Combined result for Eric & Viro]

On Sat, Oct 25, 2008 at 11:28 PM, Eric W. Biederman
<ebiederm@...ssion.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@...iv.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/