netdev - Re: [PATCH] tcp_output: Re: rare bad TCP checksum with 2.6.19?

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:	Fri, 19 Jan 2007 16:20:01 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Jarek Poplawski <jarkao2@...pl>
CC:	netdev@...r.kernel.org, Patrick McHardy <kaber@...sh.net>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH] tcp_output: Re: rare bad TCP checksum with 2.6.19?

Jarek Poplawski wrote:
> On 17-01-2007 15:12, Michael Tokarev wrote:
[]
>> Here's another sample, which may be more useful.  I've seen quite
>> alot of very similar stuff while running tcpdump.
>>
>>   http://www.corpit.ru/mjt/bad-cksum-session3-dmp.bin
>>
>> The scenario looks like this.
>>
>> A client (82.84.172.37 -- a zombie machine trying to send us spam
>> in this case) connects to a port 25 here (81.13.94.6:25).  SYN+ACK
>> sequence completes.  Next, our server send an initial SMTP greething
>> message, but almost right after that, the client sends a FIN packet,
>> WITHOUT acknowleging that it received the (first and only) data
>> packet.  So some time later our machine re-sends the data, AND adds
>> FIN flag to the packet (also replying to the FIN received from the
>> client).  And *that* packet - original data packet which is modified
>> to also include FIN - has incorrect checksum.
>>
>> So it looks like the checksum isn't being updated WHEN ADDING MORE
>> FLAGS to the original data packet.
>>
> 
> Hi,
> 
> Here is my patch proposal. If I'm not totally wrong,
> there is a possibility that, during collapsing, empty
> skb with FIN is added to "normal" packet and changes
> its ip_summed field to CHECKSUM_NONE.
> 
> Regards,
> Jarek P.
> 
> PS: probably there are also other possibilities...

Well..  I just tried it - with this patch applied, no more bad checksums
are shown.  Tried from the network that triggers it most reliable - and
wasn't able to reproduce the bad behavior.

I'm running a tcpdump right now, and so far it only captured a few bad-cksum
packets from other hosts (which are also running 2.6.19 ;)

Thanks Jarek!

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