Alexey Dobriyan <adobriyan@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
