netdev - Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp

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: <7916.1257300093@turing-police.cc.vt.edu>
Date:	Tue, 03 Nov 2009 21:01:33 -0500
From:	Valdis.Kletnieks@...edu
To:	Ilpo JÃ€rvinen <ilpo.jarvinen@...sinki.fi>
Cc:	Gilad Ben-Yossef <gilad@...efidence.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Ori Finkelman <ori@...sleep.com>
Subject: Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!

On Tue, 03 Nov 2009 23:34:19 +0200, Ilpo JÃâ¬rvinen said:

> On Tue, 3 Nov 2009, Gilad Ben-Yossef wrote:
> 
> > Eric Dumazet wrote:
> > 
> > > Valdis.Kletnieks@...edu a écrit :
> > >   
> > > > Seen right after I started 'fetchmail'.  Reproducible - 3 out of 3.
> > > > I'll bisect this tonight if nobody jumps up and yells they know what it
> > > > is...
> > > >     
> > Bah... this is most probably my fault. Sorry about that.
> > 
> > Can you please try the patch in the next email?

Tried while at home, machine panic'ed.  No netconsole here at the moment, sorry.

> > But also, can you please send me the route table in effect when this happened
> > and the fetchmail command line/config (removing any passwords or account
> > details of course)? I want to understand better when this happens.

% route -n -A inet
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
128.173.12.0    0.0.0.0         255.255.252.0   U     0      0        0 eth0
0.0.0.0         128.173.12.1    0.0.0.0         UG    0      0        0 eth0
% route -n -A inet6
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
::1/128                                     ::                                      U     0      687       1 lo
2001:468:c80:2103:215:c5ff:fec8:334e/128    ::                                      U     0      53533       1 lo
2001:468:c80:2103::/64                      ::                                      UA    256    316       0 eth0
fe80::215:c5ff:fec8:334e/128                ::                                      U     0      176       1 lo
fe80::218:deff:fe9c:24e0/128                ::                                      U     0      0        1 lo
fe80::/64                                   ::                                      U     256    0        0 eth0
fe80::/64                                   ::                                      U     256    0        0 wlan0
ff02::1/128                                 ff02::1                                 UC    0      451       0 eth0
ff00::/8                                    ::                                      U     256    0        0 eth0   
ff00::/8                                    ::                                      U     256    0        0 wlan0  
::/0                                        fe80::20f:35ff:fe3e:d41a                UGDA  1024   2082       1 eth0

Command line was just 'fetchmail'. Relevant .fetchmailrc:

set postmaster "valdis"
set bouncemail
set no spambounce
set properties ""
set daemon 240
poll imap.vt.edu with proto IMAP and options
  user 'valdis' there with password 'redacted' is 'valdis' here ssl fetchsizelimit 0 smtpaddress turing-police.cc.vt.edu

(imap.vt.edu is 198.82.183.77 - so off the local subnet)

> According to the stacktrace, it came from ipv6 side which doesn't have any 
> null checking what so ever atm (you only handled ipv4 correctly). ...You 
> should be a bit more careful next time when adding any BUG_ONs...

Why was this blowing chunks in the IPv6 when I was making an IPv4 connection
then? I just noticed that. My fetchmail can't make an IPv6 TCP connection to
our IMAP server because the server isn't v6-enabled yet.  And although I
contact our DNS over IPv6, but that's UDP not TCP.


Content of type "application/pgp-signature" skipped