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  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]
Date:	Thu, 25 Jan 2007 21:08:28 +0200
From:	Baruch Even <baruch@...en.org>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Stephen Hemminger <shemminger@...l.org>
Subject: Re: [PATCH] Fix sorting of SACK blocks

* Stephen Hemminger <shemminger@...ux-foundation.org> [070125 20:47]:
> On Thu, 25 Jan 2007 20:29:03 +0200
> Baruch Even <baruch@...en.org> wrote:
> 
> > 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>
> > 
> > diff -X 2.6-rc6/Documentation/dontdiff -ur 2.6-rc6/net/ipv4/tcp_input.c 2.6-mod/net/ipv4/tcp_input.c
> > --- 2.6-rc6/net/ipv4/tcp_input.c	2007-01-25 19:04:20.000000000 +0200
> > +++ 2.6-mod/net/ipv4/tcp_input.c	2007-01-25 19:52:04.000000000 +0200
> > @@ -1011,10 +1011,11 @@
> >  			for (j = 0; j < i; j++){
> >  				if (after(ntohl(sp[j].start_seq),
> >  					  ntohl(sp[j+1].start_seq))){
> > -					sp[j].start_seq = htonl(tp->recv_sack_cache[j+1].start_seq);
> > -					sp[j].end_seq = htonl(tp->recv_sack_cache[j+1].end_seq);
> > -					sp[j+1].start_seq = htonl(tp->recv_sack_cache[j].start_seq);
> > -					sp[j+1].end_seq = htonl(tp->recv_sack_cache[j].end_seq);
> > +					struct tcp_sack_block_wire tmp;
> > +
> > +					tmp = sp[j];
> > +					sp[j] = sp[j+1];
> > +					sp[j+1] = tmp;
> >  				}
> >  
> >  			}
> 
> This looks okay, but is there a test case that can be run?

There is nothing visible that shows the problem, the only option is to
add some code to print the SACK blocks after sorting and run it over a
large BDP connection that can be saturated. You'll obviously need to
have several holes, I believe that the bug will be visible when you have
ACK packets with three SACK blocks where the first block is the highest
which should be the normal case.

Cheers,
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

Powered by blists - more mailing lists