Most recent kernel where this bug did not occur: Distribution: n/a Hardware Environment: i686 Software Environment: n/a Problem Description: after hitting a *very hard to repro* BUG in a distro kernel I did some code inspection that seems to show that llc_rcv does not handle receive packets using skb->data *and* skb_shinfo(skb)->frags[]/nr_frags Steps to reproduce: Apparently receiving some netware (802_2) traffic when using one of the PCI-Express e1000 adapters with packet splitting enabled. Even if the packet is not split a large frame will use skb->data and ->frags[] Analysis: llc_rcv does a skb_clone inside skb_share_check llc_fixup_skb skb_trim __skb_trim ___pskb_trim(x,x,0) <-- realloc set to 0 ___pskb_trim BUG on !realloc inside skb_cloned check I'll attach the trace from the vendor kernel, I believe the problem is still relevant to 2.6.16.
Created attachment 7903 [details] distro kernel BUG output yes, this is on a distro kernel, but the bug is nearly impossible to reproduce. Please see the analysis for how it can happen on 2.6.16
Begin forwarded message: Date: Wed, 19 Apr 2006 11:32:18 -0700 From: bugme-daemon@bugzilla.kernel.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 6409] New: llc_rcv doesn't handle receives using nr_frags and frags[] http://bugzilla.kernel.org/show_bug.cgi?id=6409 Summary: llc_rcv doesn't handle receives using nr_frags and frags[] Kernel Version: 2.6.16 Status: NEW Severity: normal Owner: acme@conectiva.com.br Submitter: jesse.brandeburg@intel.com Most recent kernel where this bug did not occur: Distribution: n/a Hardware Environment: i686 Software Environment: n/a Problem Description: after hitting a *very hard to repro* BUG in a distro kernel I did some code inspection that seems to show that llc_rcv does not handle receive packets using skb->data *and* skb_shinfo(skb)->frags[]/nr_frags Steps to reproduce: Apparently receiving some netware (802_2) traffic when using one of the PCI-Express e1000 adapters with packet splitting enabled. Even if the packet is not split a large frame will use skb->data and ->frags[] Analysis: llc_rcv does a skb_clone inside skb_share_check llc_fixup_skb skb_trim __skb_trim ___pskb_trim(x,x,0) <-- realloc set to 0 ___pskb_trim BUG on !realloc inside skb_cloned check I'll attach the trace from the vendor kernel, I believe the problem is still relevant to 2.6.16. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
Reply-To: davem@davemloft.net From: Andrew Morton <akpm@osdl.org> Date: Wed, 19 Apr 2006 11:38:06 -0700 > Analysis: > llc_rcv > does a skb_clone inside skb_share_check > llc_fixup_skb > skb_trim > __skb_trim > ___pskb_trim(x,x,0) <-- realloc set to 0 > ___pskb_trim BUG on !realloc inside skb_cloned check I'll fix it like this: diff-tree 5185db09f46ed64d520d09db6e93852e44106628 (from 3672558c6180ca28a7aa46765702467a37e58fc5) Author: David S. Miller <davem@sunset.davemloft.net> Date: Wed Apr 19 15:37:13 2006 -0700 [LLC]: Use pskb_trim_rcsum() in llc_fixup_skb(). Kernel Bugzilla #6409 If we use plain skb_trim(), that's wrong, because if the SKB is cloned, and it can be because we unshared it in the caller, we have to allow reallocation. The pskb_trim*() family of routines is therefore the most appropriate here. Signed-off-by: David S. Miller <davem@davemloft.net> diff --git a/net/llc/llc_input.c b/net/llc/llc_input.c index 8f3addf..d62e0f9 100644 --- a/net/llc/llc_input.c +++ b/net/llc/llc_input.c @@ -118,7 +118,8 @@ static inline int llc_fixup_skb(struct s u16 pdulen = eth_hdr(skb)->h_proto, data_size = ntohs(pdulen) - llc_len; - skb_trim(skb, data_size); + if (unlikely(pskb_trim_rcsum(skb, data_size))) + return 0; } return 1; }
testing to see if this patch fixes the issue.