[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzKet5sASgrD==8iZ5m1+-FDpznfuqcNDS5ZyCocwzAbg@mail.gmail.com>
Date: Wed, 22 Feb 2012 10:16:38 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Ian Kent <raven@...maw.net>, David Miller <davem@...emloft.net>,
linux-kernel@...r.kernel.org, autofs@...r.kernel.org,
Thomas Meyer <thomas@...3r.de>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: compat: autofs v5 packet size ambiguity - update
On Wed, Feb 22, 2012 at 9:45 AM, H. Peter Anvin <hpa@...or.com> wrote:
>
> Incidentally, a valid user space workaround for this problem would be to
> just read all the data off the pipe but consider the packet length to be
> NAME_MAX rather than NAME_MAX+1; then simply discard all-zero ints
> received on input since a packet always starts with the autofs version
> number.
Nope, won't work.
Why?
Because that padding word for size is just random data.
In fact, we probably should clear it. I suspect we leak kernel stack
contents to autofs. Not that it matters (system daemon with root
privileges and all that), but it's another case of the whole "packing
data structures" issue.
Of course, right now autofs leaks kernel stack way more than that one
possible alignment word: the whole "name[NAME_MAX+1]" array is leaking
stuff after the name length (and final zero). So the padding is the
least of the leaking worries.
But the point is that because of very similar issues, the user-space
daemon cannot rely on things being zero.
Unless you fix the kernel, and increment the version number. But once
you do that, you're better off just fixing the size anyway.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists