From: Ido Schimmel <idosch@nvidia.com>
To: Eric Dumazet <edumazet@kernel.org>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, David Ahern <dsahern@kernel.org>,
netdev@vger.kernel.org, Florian Westphal <fw@strlen.de>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Phil Sutter <phil@nwl.cc>
Subject: Re: [PATCH v2 net] inet: frags: bound the wmem charge of the socket completing a reassembly
Date: Mon, 9 Nov 2026 10:06:58 +0200 [thread overview]
Message-ID: <20261109080658.GA1454873@shredder> (raw)
In-Reply-To: <20261104122927.1033747-1-edumazet@kernel.org>
On Wed, Nov 04, 2026 at 01:29:27PM +0100, Eric Dumazet wrote:
> When a socket owned fragment completes a reassembly queue,
> inet_frag_reasm_prepare() and inet_frag_reasm_finish() charge the
> truesize of all other fragments to its sk_wmem_alloc. These fragments
> were orphaned when queued, and might have been sent by someone else,
> for instance padded TUN packets.
>
> Commit 3ae20e4697eb ("inet: frags: limit the truesize of a reassembly
> queue") bounds this charge to INT_MAX / 2 per queue, but a socket can
> complete several queues while the reassembled skbs are still alive,
> for instance held in a qdisc. sk_wmem_alloc can then go past INT_MAX,
> refcount_add() saturates it with a WARN, and the socket is leaked.
>
> This is reachable from an unprivileged user/network namespace, by
> raising ipfrag_high_thresh.
>
> Refuse the reassembly if the charge would push sk_wmem_alloc above
> 2 * sk_sndbuf, the bound ip_append_data() uses, plus 4MB of slack for
> fragments inflated by a refragmentation with a small MTU, and never
> above INT_MAX / 2. The cap matters for tun sockets, which use
> sk_sndbuf = INT_MAX, and whose skbs are still owned when act_ct or
> openvswitch reassemble them at ingress.
>
> Several queues can complete at the same time on different cpus for
> the same socket, so the charge is reserved with a cmpxchg() loop in
> inet_frag_reasm_prepare(), before it modifies the queue, and settled
> in inet_frag_reasm_finish(). Move the size checks of ip_frag_reasm(),
> ip6_frag_reasm() and nf_ct_frag6_reasm() before
> inet_frag_reasm_prepare(), using the first fragment which becomes the
> head, so that a successful inet_frag_reasm_prepare() is always followed
> by inet_frag_reasm_finish(). All callers already kill the queue when
> inet_frag_reasm_prepare() returns NULL.
>
> Found by code inspection (AI review), not reproduced.
>
> Fixes: 18685451fc4e ("inet: inet_defrag: prevent sk release while still in use")
> Reported-by: Paolo Abeni <pabeni@redhat.com>
> Closes: https://lore.kernel.org/netdev/24feda7d-ae49-45af-9596-2cc5f149f28e@redhat.com/
> Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
next prev parent reply other threads:[~2026-11-09 8:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 12:29 [PATCH v2 net] inet: frags: bound the wmem charge of the socket completing a reassembly Eric Dumazet
2026-11-09 8:06 ` Ido Schimmel [this message]
2026-11-10 9:10 ` patchwork-bot+netdevbpf
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=20261109080658.GA1454873@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@kernel.org \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/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.