netdev - Re: Linux 2.6.22: Leak r=1 1

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]

Date:	Thu, 12 Jul 2007 16:56:20 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Sami Farin <safari-kernel@...ari.iki.fi>
cc:	David Miller <davem@...emloft.net>,
	Linux Networking Mailing List <netdev@...r.kernel.org>
Subject: Re: Linux 2.6.22: Leak r=1 1

On Thu, 12 Jul 2007, Sami Farin wrote:

> On Thu, Jul 12, 2007 at 10:53:57 +0300, Ilpo Järvinen wrote:
> > On Wed, 11 Jul 2007, Sami Farin wrote:
> > 
> > > That's right, so descriptive is the new Linux kernel 2.6.22.
> > > Took a while to grep what is "leaking".
> > > 
> > > Linux safari.finland.fbi 2.6.22-cfs-v19 #3 SMP Tue Jul 10 00:22:25 EEST 2007 i686 i686 i386 GNU/Linux
> > > 
> > > Just normal Internet usage, azureus for example =)
> > > I think this is easy to trigger.
> > 
> > I guess those packet loss periods help you to reproduce it so easily.
> ...
> > I'd be interested to study some tcpdumps that relate to Leak cases you're 
> > seeing. Could you record some Sami? I'm not sure though how one can figure 
> 
> I now have 300 MB capture and several new&retarded music videos...
> And 10 WARNINGs and 0 Leak printk's.

Thanks, every warning would have lead to a Leak print later on (not 
necessarily with 1-to-1 relation but every pending warning would be 
"acknowledged" by a single Leak print). So every time the WARNING 
triggers, inconsistency would have been result without the patch.

> 2007-07-12 12:03:18.910712500 <4>[ 1318.606826] WARNING: at net/ipv4/tcp_input.c:1402 tcp_enter_frto_loss()
...snip...

> This is MAYBE the guilty connection if timestamps are to be believed:

...snip...

I think you got the correct connection... Thanks. The problem seems to
be related to FIN (a case that wouldn't have occurred to me without your 
log, thanks again :-))... I think that the patch I suggested should be 
fine (and it fixes the fuzzy sack block issues as well) though I still 
have problem in figuring out what's the exact path of execution on each 
ACK near the end of the connection (the sent packets are misplaced in the 
shown dump but the original order can be reconstructed from IP identifiers 
and TCP timestamps).

> Well, haven't gotten Leaks anymore after applying the patch.

I'd have been a bit surprised if they would have still been there with 
the patch...

-- 
 i.