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

[ebiederm@xmission.com (Eric W. Biederman)]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> 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').
>> 
>> If we explicitly clear the buffer before calling readlink, we can also
>> see that some garbage has been filled in there, after the string:
>> 
>> # ./readlink /proc/4762/exe
>> readlink(/proc/4762/exe) = 30
>>
> 2f7362696e2f7564657664000000ffffffad4effffffadffffffdeffffffffffffffff202864656c657465642900000000000000000000000000000
>> 
>> (Output is from following simple program:)
>> 
>> #include <stdio.h>
>> #include <string.h>
>> #include <unistd.h>
>> 
>> int main(int argc, char *argv[])
>> {
>>         char buf[1024];
>>         int i;
>>         ssize_t n;
>> 
>>         memset(buf, 0, sizeof(buf));
>>         n = readlink(argv[1], buf, sizeof(buf));
>> 
>>         printf("readlink(%s) = %d\n", argv[1], n);
>> 
>>         for (i = 0; i < sizeof(buf); ++i)
>>                 printf("%02x", buf[i]);
>>         printf("\n");
>> 
>>         return 0;
>> }
>> 
>> It was discovered by kmemcheck:
>> 
>> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f6a109e4)
>> 64000000ad4eaddeffffffffffffffff000000000200000000000000c0838ff8
>>  i i u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u
>>          ^
>> 
>> Pid: 21511, comm: readlink Not tainted (2.6.28-rc1 #58) 945P-A
>> EIP: 0060:[<c04f988d>] EFLAGS: 00000296 CPU: 0
>> EIP is at __d_path+0x8d/0x1c0
>> EAX: 0000000e EBX: d7ba0fe7 ECX: 00000001 EDX: f68b0b40
>> ESI: f6a109e4 EDI: d7ba0fef EBP: e58c3f28 ESP: c2569c08
>>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>> CR0: 8005003b CR2: f6c1d704 CR3: 31fc7000 CR4: 00000650
>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> DR6: ffff4ff0 DR7: 00000400
>>  [<c04fa4b0>] d_path+0xb0/0xd0
>>  [<c052c37c>] proc_pid_readlink+0x6c/0xc0
>>  [<c04eda34>] sys_readlinkat+0x94/0xa0
>>  [<c04eda67>] sys_readlink+0x27/0x30
>>  [<c0422f83>] sysenter_do_call+0x12/0x3f
>>  [<ffffffff>] 0xffffffff
>> 
>> Line numbers are these (as of commit
>> e013e13bf605b9e6b702adffbe2853cfc60e7806 in Linus's tree):
>> 
>> $ addr2line -e vmlinux -i c04f988d c04fa4b0 c052c37c c04eda34 c04eda67
>> fs/dcache.c:1895
>> fs/dcache.c:1901
>> fs/dcache.c:1957
>> fs/dcache.c:2016
>> fs/proc/base.c:1347
>> fs/proc/base.c:1374
>> fs/stat.c:312
>> fs/stat.c:325
>> 
>> I couldn't immediately figure out who/what to blame, please Cc in
>> right direction if you think you know it :-)
>
> Well, I only can say who may be interested (CCs added).

Weird.  The dentry for "udevd" has an incorrect length.
Is something stomping the length somewhere?

What filesystem does /sbin/udevd reside on?

Eric