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: <20080710.030920.141237050.davem@davemloft.net>
Date:	Thu, 10 Jul 2008 03:09:20 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	avivgnet@...il.com
Cc:	mchan@...adcom.com, joy@...ian.org, billfink@...dspring.com,
	bhutchings@...arflare.com, netdev@...r.kernel.org,
	mirrors@...ian.org
Subject: Re: bnx2_poll panicking kernel

From: "Aviv Greenberg" <avivgnet@...il.com>
Date: Thu, 10 Jul 2008 12:45:54 +0300

> On Thu, Jul 10, 2008 at 02:46, David Miller <davem@...emloft.net> wrote:
> >
> > So it has to be something else.
> 
> What mechanism prevents the clone from happening between
> the skb_clone() and skb_split() calls in tcp_fragment?

The TCP packet is guarenteed to be cloned when the driver
first gets it.  That's fundamentally how TCP's retransmission
handling works.

It makes a clone, and sends it down to the driver.

You can't make clones of clones, so in such situations
code makes a full copy instead.

TCP always had the whole state of the retransmit queue,
and thus the base SKB state, locked when it makes all
of these operations.

When TCP is looking at an SKB on the retransmit queue it can only go
from cloned to uncloned, not the other way around.

> Maybe there's a path that doesn't take a lock...

I doubt it.

I think it's some piece of code not making careful enough
checks on the way down to an SKB modification.
--
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