linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: "Andrew Morton" <akpm@linux-foundation.org>
Cc: "Alexey Dobriyan" <adobriyan@gmail.com>,
	greg@kroah.com, mingo@elte.hu, viro@zeniv.linux.org.uk,
	ebiederm@xmission.com, Yoshiya.Koyama@hp.com, rjw@sisk.pl,
	penberg@cs.helsinki.fi, linux-kernel@vger.kernel.org,
	kay.sievers@vrfy.org, linux-fsdevel@vger.kernel.org
Subject: Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace
Date: Tue, 11 Nov 2008 23:53:56 +0100	[thread overview]
Message-ID: <19f34abd0811111453q51412aaas3cd01cc2e8398cd7@mail.gmail.com> (raw)
In-Reply-To: <20081111141412.b52469d2.akpm@linux-foundation.org>

On Tue, Nov 11, 2008 at 11:14 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> I queued the below for 2.6.28 inclusion and tagged for -stable
> backporting.
>
>
>
> From: Al Viro <viro@ZenIV.linux.org.uk>
>
> Vegard sayeth:
>
> 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];

Should probably have been unsigned char.

>        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]);

Or maybe it was the wrong format string. Negative numbers become very
long (with many extra "ff"s) in output. I guess it doesn't really
matter, though...

That said, Alexey also had an error in HIS testcase:

On Tue, Nov 4, 2008 at 11:34 AM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <string.h>
> #include <unistd.h>
>
> int main(void)
> {
>        int fd, fd1;
>        char buf[64], buf1[64], img[42000];
>        ssize_t len;
>
>        fd = open("/proc/self/exe", O_RDONLY);
>
>        readlink("/proc/self/exe", buf, sizeof(buf));
>        strcpy(buf1, buf);
>        strcat(buf1, ".xxx");
>        unlink(buf1);
>        fd1 = open(buf1, O_WRONLY|O_CREAT);

Without the third argument to open with O_CREAT, file permissions may
be very strange :-)

Is this small program suitable for inclusion in LTP, maybe? We can
verify that kernel does the right thing by testing readlink(buf) ==
strlen(buf).

But thanks for the fix and attribution!


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

  reply	other threads:[~2008-11-11 22:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-25 17:14 v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace Vegard Nossum
2008-10-25 20:41 ` Rafael J. Wysocki
2008-10-25 22:28   ` Eric W. Biederman
2008-10-26 21:08     ` Vegard Nossum
2008-11-04  9:39       ` Vegard Nossum
2008-11-04 10:00         ` Alexey Dobriyan
2008-11-04 10:07           ` Alexey Dobriyan
2008-11-04 10:34             ` Alexey Dobriyan
2008-11-04 10:54           ` Eric W. Biederman
2008-11-04 15:48             ` Al Viro
2008-11-04 15:12         ` Al Viro
2008-11-06 10:04           ` Ingo Molnar
2008-11-07 19:05             ` Greg KH
2008-11-07 23:12               ` Alexey Dobriyan
2008-11-11 22:14                 ` Andrew Morton
2008-11-11 22:53                   ` Vegard Nossum [this message]
2008-12-03 17:18                   ` Greg KH
2008-12-03 20:20                     ` Andrew Morton
2008-12-07  5:44                       ` Greg KH
2008-12-07  7:04                         ` Al Viro
2008-10-26  0:23 ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19f34abd0811111453q51412aaas3cd01cc2e8398cd7@mail.gmail.com \
    --to=vegard.nossum@gmail.com \
    --cc=Yoshiya.Koyama@hp.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=rjw@sisk.pl \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).