netdev - Re: Reported regression against commit a05d2ad

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] [day] [month] [year] [list]

Message-ID: <m1y60tlp9j.fsf@fess.ebiederm.org>
Date:	Wed, 22 Jun 2011 11:00:56 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	tim.gardner@...onical.com
Cc:	Herton Ronaldo Krzesinski <herton.krzesinski@...onical.com>,
	lamont@...onical.com, sconklin@...onical.com,
	netdev@...r.kernel.org
Subject: Re: Reported regression against commit a05d2ad

Tim Gardner <tim.gardner@...onical.com> writes:

> On 06/21/2011 02:49 PM, Eric W. Biederman wrote:
> <snip>
>> I respectfully suggest that the bug is elsewhere perhaps a broken user
>> space application out there that needs to be fixed, or you have a kernel
>> memory stomp that removing patch a05d2ad happens to shift the memory
>> layout to be harmful in a different way.
>>
>
> OK, I'm remembering how PF_UNIX Unix domain sockets are used, so I think your
> theory about a misbehaving user space application is more likely. However, I am
> a bit confused about how an application can attempt to receive before the socket
> is fully opened. Some kind of race condition with socketpair() ?

The case that is relevant is a listening SOCK_SEQPACKET socket.

The case that is affected is when you call receive on a listening
socket.

It isn't that the socket isn't fully opened.  It is that accept is the
only legitimate operation at that point.

It took a mistake while someone was developing an application for this
kernel bug to be found.

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html