From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace Date: Tue, 04 Nov 2008 02:54:35 -0800 Message-ID: References: <19f34abd0810251014s7968557br38e43aa0b9cdcf09@mail.gmail.com> <200810252241.53601.rjw@sisk.pl> <19f34abd0810261408w61b1e2dbvb9a0e16ce5a10022@mail.gmail.com> <19f34abd0811040139t8334502i7a5d8501c5fe95ac@mail.gmail.com> <20081104100050.GA10398@x200.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Vegard Nossum , Al Viro , "Koyama, Yoshiya" , "Rafael J. Wysocki" , Ingo Molnar , Pekka Enberg , LKML , Greg KH , Kay Sievers , linux-fsdevel@vger.kernel.org To: Alexey Dobriyan Return-path: Received: from out01.mta.xmission.com ([166.70.13.231]:42156 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751447AbYKDKzM (ORCPT ); Tue, 4 Nov 2008 05:55:12 -0500 In-Reply-To: <20081104100050.GA10398@x200.localdomain> (Alexey Dobriyan's message of "Tue, 4 Nov 2008 13:00:50 +0300") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Alexey Dobriyan 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