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: <20091215.205055.193693273.davem@davemloft.net>
Date:	Tue, 15 Dec 2009 20:50:55 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	john.dykstra1@...il.com, lists@...dbynature.de,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	gilad@...efidence.com
Subject: Re: Badness at net/ipv4/inet_connection_sock.c:293

From: David Miller <davem@...emloft.net>
Date: Mon, 14 Dec 2009 23:18:40 -0800 (PST)

> From: David Miller <davem@...emloft.net>
> Date: Mon, 14 Dec 2009 14:35:22 -0800 (PST)
> 
>> From: Eric Dumazet <eric.dumazet@...il.com>
>> Date: Mon, 14 Dec 2009 20:23:32 +0100
>> 
>>> If you disable syncookies, I presume you dont have warnings ?
>> 
>> It happens even with syncookies disabled, hmmm...
> 
> FWIW, I'm starting to bisect this.

Ok, it's the patch series that adds all of the per-route
SACK/DSACK/TIMESTAMP controls.

I hand reverted the entire series and the badness triggers no longer
occur.  I couldn't bisect through the individual changes because of
all of the bug fixes that happened at the end of them.

I'm pretty sure the problem eminates from changing the 'estab'
parameter passed into tcp_parse_options() from
tcp_timewait_state_process() and tcp_check_req().

But even if we fix that, this patch series is very fundamentally
broken.  It takes the 'dst' for the listening socket when creating new
incoming connections in tcp_check_req() to probe the per-route settings.

Listening sockets don't have a route.  So this can't ever work
properly.

And getting the route for the child request we're making (the right
one) can't be done until we setup all of the state and call down into
the code which emits the SYN+ACK packet and look the route up by hand.

I'm simply going to revert this entire series.  Sorry this didn't work
out, but we're not adding this feautre this time around.  Maybe you
can write a working version for the next merge widnow.
--
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