linux-kernel - Re: [PATCH v2] Introduce a version6 of autofs interface, to fix design error.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Apr 2012 16:07:21 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	David Miller <davem@...emloft.net>, mjt@....msk.ru,
	linux-kernel@...r.kernel.org, autofs@...r.kernel.org,
	raven@...maw.net, thomas@...3r.de, stable@...nel.org
Subject: Re: [PATCH v2] Introduce a version6 of autofs interface, to fix
 design error.

On Fri, Apr 27, 2012 at 3:56 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> I guess, though, what you're saying is to change the semantic of the
> existing pipe to return short reads on the receive end.

The important change is actually to make the read return the size requested.

So broken user space does a read() with the wrong size - and then
checks that it gets *exactly* that many bytes. Not more, not less.

The way to handle that is to
 - make sure the kernel always writes the maximally padded data
 - make the packetization simply drop any data that was in the packet
that the reader didn't ask for.

This is very much a semantic change, in that any client that tries to
read the packet with multiple reads (one 4-byte read to see the size,
followed by one "right-sized" read of the data) would be totally
screwed. The first read would indeed read the size, but it also -
because of the packetized interface - would simply drop the data, and
the next read would read the first bytes of the next packet.

But that's not what the autofs users actually do anyway. They just
read the whole packet.  So we can make *them* work. And the new
interface will be fairly robust (in fact, you could pass it some big
buffer and just know you always get exactly one packet, and never have
that whole stupid "sizeof()" at all).

                           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/