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]
Message-ID: <m1hb7inbvl.fsf@fess.ebiederm.org>
Date:	Tue, 21 Jun 2011 13:54:54 -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:15 PM, Herton Ronaldo Krzesinski wrote:
>> Hi,
>>
>> after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
>> got a regression report about timeout in tcp connections
>> (https://launchpad.net/bugs/791512).
>>
>> We tried help reporter with a bisect process, but it was taking some
>> time, so we reverted some suspect commits, until we isolated it to
>> commit "af_unix: Only allow recv on connected seqpacket sockets."
>>
>> With only commit a05d2ad reverted, testing results so far indicate the
>> issue doesn't happen.
>>
>> I'm unfamiliar with unix sockets code, so can't see at first why this
>> commit in particular is causing problems, for now I can only say may be
>> something at application level using unix sockets regressed with it (?).
>> I'm just reporting it right now, and we plan to revert it for that kernel
>> until more info is found about it.
>>
>> I'm adding reporter to CC (Lamont), in case more details are necessary
>> etc.
>>
>
> I believe we're also homing in on the same regression in 2.6.38.6 ('af_unix:
> Only allow recv on connected seqpacket sockets.'). The functional part of the
> patch is:
>
> +
> +       if (sk->sk_state != TCP_ESTABLISHED)
> +               return -ENOTCONN;
> +
> +       return unix_dgram_recvmsg(iocb, sock, msg, size, flags);
>
> What happens with out of order receives? Would fragmentation have an
> impact?

That code path has absolutely nothing to do with packets that come in
over the wire.  Zilch, zero, nada.  Fragments don't matter because
fragments can not possibly hit that code path.  IP packets can not
possibly hit that code path.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ