From: Patrick McHardy <kaber@trash.net>
To: ben@bigfootnetworks.com
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: Bridge + Conntrack + SKB Recycle: Fragment Reassembly Errors
Date: Tue, 01 Dec 2009 17:24:23 +0100 [thread overview]
Message-ID: <4B154337.8060702@trash.net> (raw)
In-Reply-To: <767BAF49E93AFB4B815B11325788A8ED4B1FDC@L01SLCXDB03.calltower.com>
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
ben@bigfootnetworks.com wrote:
>> Ben, please give this patch a try.
>
> I have not been able to recreate the issue after applying the patch,
> which is great.
Thanks for testing.
> Is this the only case in which large-ish SKBs might be
> recycled and cause the reassembly overflow?
I'm not aware of any other cases at least.
Dave, attached is the patch again with a proper changelog.
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 1421 bytes --]
commit d45f8b9ff2b7c1c5787348a39d3778931beca7e3
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Dec 1 17:19:14 2009 +0100
ip_fragment: also adjust skb->truesize for packets not owned by a socket
When a large packet gets reassembled by ip_defrag(), the head skb
accounts for all the fragments in skb->truesize. If this packet is
refragmented again, skb->truesize is not re-adjusted to reflect only
the head size since its not owned by a socket. If the head fragment
then gets recycled and reused for another received fragment, it might
exceed the defragmentation limits due to its large truesize value.
skb_recycle_check() explicitly checks for linear skbs, so any recycled
skb should reflect its true size in skb->truesize. Change ip_fragment()
to also adjust the truesize value of skbs not owned by a socket.
Reported-and-tested-by: Ben Menchaca <ben@bigfootnetworks.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index b78e615..e34013a 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -503,8 +503,8 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
if (skb->sk) {
frag->sk = skb->sk;
frag->destructor = sock_wfree;
- truesizes += frag->truesize;
}
+ truesizes += frag->truesize;
}
/* Everything is OK. Generate! */
next prev parent reply other threads:[~2009-12-01 16:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-10 16:09 Bridge + Conntrack + SKB Recycle: Fragment Reassembly Errors ben
2009-11-10 16:50 ` Patrick McHardy
2009-11-21 19:08 ` David Miller
2009-11-22 0:21 ` Patrick McHardy
2009-11-22 0:29 ` Patrick McHardy
2009-12-01 16:00 ` ben
2009-12-01 16:24 ` Patrick McHardy [this message]
2009-12-01 23:54 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B154337.8060702@trash.net \
--to=kaber@trash.net \
--cc=ben@bigfootnetworks.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.