linux-kernel - Re: Badness at net/ipv4/inet_connection

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 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/