netdev - Re: bnx2_poll panicking kernel

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: <48602847.1020203@broadcom.com>
Date:	Mon, 23 Jun 2008 15:48:39 -0700
From:	"Michael Chan" <mchan@...adcom.com>
To:	"Josip Rodin" <joy@...uzijast.net>
cc:	"'Bill Fink'" <billfink@...dspring.com>,
	"Ben Hutchings" <bhutchings@...arflare.com>,
	netdev <netdev@...r.kernel.org>,
	"mirrors@...ian.org" <mirrors@...ian.org>
Subject: Re: bnx2_poll panicking kernel

Josip Rodin wrote:
> On Mon, Jun 23, 2008 at 08:04:39PM +0200, Josip Rodin wrote:
>> Oh, duh, yes, I'm a moron. It's back on now, sorry about that.
> 
> There we go, I got the debugging messages:
> 
> [...]
> Jun 23 19:53:18 arrakis kernel: HTB: quantum of class 10100 is big. Consider r2q change.
> Jun 23 22:57:55 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 4
> Jun 23 22:58:32 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 2
> Jun 23 22:59:02 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 3
> Jun 23 22:59:23 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 9
> Jun 23 22:59:36 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 3
> Jun 23 23:08:19 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 3
> 

OK, this definitely confirms the theory that the skb->nr_frags is changed
between ->hard_start_xmit() and tx completion.  Since we rely on nr_frags to
locate the packet boundaries in the tx ring, it would definitely crash.

One possibility is that it is corrupted by the driver and only happens when
there are HTB rules.  I think this is unlikely.

TG3 which operates the same way has also been reported to crash in the
presence of HTB rules.  We were not able to pinpoint the problem at that
time.

Can anyone think of a scenario where the stack can modify the SKB this way?
These SKBs look like they are TSO packets.  

If not, I will send Josip another patch to print more SKB fields.  I can
even save all the SKB fields and see which other ones are modified besides
the nr_frags.  May be that will give us a better clue.

Thanks.

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