netdev - Re: [PATCH] Fix sorting of SACK blocks

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: <20070126064009.GE22455@galon.ev-en.org>
Date:	Fri, 26 Jan 2007 08:40:09 +0200
From:	Baruch Even <baruch@...en.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, shemminger@...l.org
Subject: Re: [PATCH] Fix sorting of SACK blocks

* David Miller <davem@...emloft.net> [070126 01:55]:
> From: Baruch Even <baruch@...en.org>
> Date: Thu, 25 Jan 2007 20:29:03 +0200
> 
> > The sorting of SACK blocks actually munges them rather than sort, causing the
> > TCP stack to ignore some SACK information and breaking the assumption of
> > ordered SACK blocks after sorting.
> > 
> > The sort takes the data from a second buffer which isn't moved causing
> > subsequent data moves to occur from the wrong location. The fix is to
> > use a temporary buffer as a normal sort does.
> > 
> > Signed-Off-By: Baruch Even <baruch@...en.org>
> 
> BTW, in reviewing this I note that there is now only one remaining
> use of tp->recv_sack_cache[] and that is the code earlier in this
> function which is trying to detect if all we are doing is extending
> the leading edge of a SACK block.
> 
> It would be nice to be able to clear out that usage as well, and
> remove recv_sack_cache[] and thus make tcp_sock smaller.

You actually need recv_sack_cache to detect if you can use the fast
path. Another alternative is to somehow hash the values of the sack
blocks but then you rely on probabilty that you will properly detect the
ability to use the fast path. Hashing will save some space but you can't
get rid of it completely unless you go back to the old and slow method
of SACK processing.

There were thoughts thrown a while back about using a different data
structure, I think you said you started working on something like that.
If that comes to fruition the cache might go.

FWIW, my other mail about possible bugs actually says that you might
need to add another value to check, the number of sack blocks in the
cache.

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