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

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

Alexey Dobriyan <adobriyan@gmail.com> writes:

> On Tue, Nov 04, 2008 at 10:39:19AM +0100, Vegard Nossum wrote:
>> # uname -a
>> Linux ubuntu 2.6.28-rc2-next-20081031 #60 SMP Sat Nov 1 13:19:49 CET
>> 2008 i686 GNU/Linux
>> # prelink -mRf /sbin/udevd
>> # ./a.out /proc/4764/exe
>> warning: /proc/4764/exe: got return value 38, expected 11
>> 2f7362696e2f756465766400fffffffffdfffffffffffff7ffffbfff202864656c6574656429
>> /sbin/udevd                  (deleted)
>
> reproduced
>
> As I said previously, kmemcheck rocks (slowly). :-)

It is reproducible here as well.  At least to the point of the
strange readlink length.

prelink generates a new executable and renames it on top
of the old executable.  So I'm guessing something on the unlink
and rename path is what is giving us the strange length.

Hmm.  The string: '/sbin/udevd.#prelink#.J9NyXV (deleted)'
is 38 bytes long...   So I'm guessing d_move is doing something
wrong and we are not seeing the name string we expect.

Why do we see /sbin/udevd and not /sbin/udevd.#prelink#.J9NyXV 
after d_move.  It looks like both names are short enough that
they are inline.

Oh.  I see.  switch_names when both names are internal,
does a memcpy of the new name to the target name,
but it doesn't do anything with the source name.
Then later we swap the name lengths.

So the length on the dentry no longer matches the data
we put in the buffer.

Certainly not a resource leak or any kind of deadlock.
And the length is right.  But it is an information leak.

I suppose a clever person could figure out how to steal
information that way.

The nice fix would be to keep the old length in this case,
so we don't have a name mangled because someone renamed
on top of us.  But that is inconsistent.


Eric