From: Qihang <q.h.hack.winter@gmail.com>
To: netdev@vger.kernel.org
Cc: steffen.klassert@secunet.com, Christian Hopps <chopps@labn.net>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, David Ahern <dsahern@kernel.org>,
Ido Schimmel <idosch@nvidia.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4 3/3] xfrm: hold the tunnel device reference across the input path
Date: Mon, 19 Oct 2026 15:33:30 +0000 [thread overview]
Message-ID: <1792424010.89978.05cf1ab60e@gmail.com> (raw)
In-Reply-To: <20261018090638.55686-3-q.h.hack.winter@gmail.com>
The [High] finding is valid, thanks.
__input_process_payload() reaches the drop label from several inner-packet
validation failures, and the drop label sits after the loop that delivers
the packets queued on @sublist. When the outer skb is reused in place for
the first inner packet it is already on @sublist and carries the cached
tunnel device reference, so jumping to the drop label skipped delivery and
left both the skb and its tunnel device reference behind; the same applies
to a packet queued by iptfs_reassem_cont().
v5 drops whatever is still queued on @sublist in the drop path through
xfrm_input_drop(), so the reference is released. The normal path already
empties @sublist, so the added loop only runs on the early-error path.
A revert-based runtime check agrees: with an aggregated IPTFS payload whose
first inner packet is complete and whose second inner packet has an invalid
IPv4 header length, v5 completes RTM_DELLINK, while the same code without
the drain leaks the reference and unregister_netdevice() waits for vti0
(Usage count = 2).
v5 sent separately.
pw-bot: cr
next prev parent reply other threads:[~2026-10-19 15:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 9:06 [PATCH net v4 0/3] xfrm: fix vti tunnel device use-after-free across async crypto resumption Qihang
2026-10-18 9:06 ` [PATCH net v4 1/3] xfrm: run the receive callback before dropping the skb->dev reference Qihang
2026-10-19 9:40 ` netdev-bot+sashiko
2026-10-18 9:06 ` [PATCH net v4 2/3] xfrm: set the address family before the early invalid-state drop Qihang
2026-10-19 9:40 ` netdev-bot+sashiko
2026-10-19 15:33 ` Qihang [this message]
2026-10-18 9:06 ` [PATCH net v4 3/3] xfrm: hold the tunnel device reference across the input path Qihang
2026-10-19 9:40 ` netdev-bot+sashiko
2026-10-18 9:13 ` [PATCH net v4 0/3] xfrm: fix vti tunnel device use-after-free across async crypto resumption netdev-bot+sinfo
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=1792424010.89978.05cf1ab60e@gmail.com \
--to=q.h.hack.winter@gmail.com \
--cc=chopps@labn.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.com \
/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.