From: Qihang <q.h.hack.winter@gmail.com>
To: netdev@vger.kernel.org
Cc: steffen.klassert@secunet.com, chopps@labn.net,
herbert@gondor.apana.org.au, davem@davemloft.net,
edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, dsahern@kernel.org, idosch@nvidia.com,
linux-kernel@vger.kernel.org
Subject: [PATCH net v5 0/3] xfrm: fix vti tunnel device use-after-free across async crypto resumption
Date: Mon, 19 Oct 2026 23:32:44 +0800 [thread overview]
Message-ID: <20261019153247.89957-1-q.h.hack.winter@gmail.com> (raw)
This replaces the earlier vti/vti6 series and the reference-transfer
rework.
vti_input() and vti6_input_proto() cache the tunnel pointer in the skb
control buffer without taking a reference. With async crypto, the
receive callback runs from crypto completion and may run after the
tunnel device has been torn down, causing a use-after-free when the
callback dereferences the cached tunnel.
The input hook takes a reference on the tunnel device when caching the
tunnel. A successful receive callback leaves the cached tunnel in place;
xfrm_input() releases the reference on every exit, including after
delivery and on drop paths. The error callback only updates the error
counters, so the common drop path releases the tunnel reference after
the skb has been freed. IPTFS, which can free or consume the outer skb
itself, releases the reference through xfrm_input_drop() or
xfrm_input_consume().
Patch 3 relies on the first two patches: the receive callback must run
before the async skb->dev reference is dropped, and the address family
must be available on the early invalid-state drop path.
Changes since v4:
- IPTFS: when an inner packet fails validation, __input_process_payload()
can reach the drop path before the inner packets queued for delivery
are sent. Drop those queued packets as well so the outer skb's tunnel
device reference is not leaked (found by the Sashiko review of v4 3/3).
Changes since v3:
- the cached pointer is always a tunnel; the address family selects its
type, and a non-NULL tunnel slot denotes one held device reference
- xfrm_input() takes the tunnel device out of the skb before
gro_cells_receive()/transport_finish(), which may consume the skb
- the device reference is dropped only after the skb has been freed,
including on error paths
- IPTFS passes the state's address family explicitly instead of
inferring it from the secpath; consumed skbs keep consume_skb()
semantics and drop paths keep their skb drop reason
- drop the xfrmi changes: it re-looks up the interface and does not
participate in the reference transfer
- merge the reference and IPTFS changes into one patch so the series
remains bisectable
- the gro_cells NAPI window is pre-existing and is documented, not
changed
Runtime testing (aarch64 QEMU; KASAN for UAF detection):
- VTI async success and error: RTM_DELLINK completes without a KASAN
report; the unfixed tree reports slab-use-after-free in vti_rcv_cb.
- Async resume with the SA deleted during the crypto window: the
reference is released and the device is removed; with patch 2
reverted, xfrm_input_take_tunnel_dev() warns and
unregister_netdevice() waits for vti0.
- IPTFS outer-skb free: RTM_DELLINK completes; with the
!first_skb xfrm_input_drop() reverted to kfree_skb(), the reference
leaks and unregister_netdevice() waits for vti0.
- IPTFS aggregated payload with a valid first inner packet followed by
an inner packet with an invalid IPv4 header length: RTM_DELLINK
completes; without the sublist drain, the tunnel device reference
leaks and unregister_netdevice() waits for vti0 (Usage count = 2).
The IPTFS timer/reorder/state-teardown paths are covered by code audit,
not by dedicated runtime triggers.
Previous versions:
https://lore.kernel.org/netdev/20261018090638.55686-1-q.h.hack.winter@gmail.com/ (v4)
https://lore.kernel.org/netdev/20261013074610.17808-1-q.h.hack.winter@gmail.com/ (v2)
https://lore.kernel.org/netdev/20260930090813.73901-1-q.h.hack.winter@gmail.com/ (v1)
Qihang
Qihang (3):
xfrm: run the receive callback before dropping the skb->dev reference
xfrm: set the address family before the early invalid-state drop
xfrm: hold the tunnel device reference across the input path
net/ipv4/ip_vti.c | 3 ++
net/ipv6/ip6_vti.c | 2 ++
net/ipv6/xfrm6_input.c | 3 ++
net/xfrm/xfrm_inout.h | 4 +++
net/xfrm/xfrm_input.c | 63 +++++++++++++++++++++++++++++++++++++++++-
net/xfrm/xfrm_iptfs.c | 42 ++++++++++++++++++----------
6 files changed, 105 insertions(+), 19 deletions(-)
--
2.54.0 (Apple Git-157)
next reply other threads:[~2026-10-19 15:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 15:32 Qihang [this message]
2026-10-19 15:32 ` [PATCH net v5 1/3] xfrm: run the receive callback before dropping the skb->dev reference Qihang
2026-10-19 15:32 ` [PATCH net v5 2/3] xfrm: set the address family before the early invalid-state drop Qihang
2026-10-19 15:32 ` [PATCH net v5 3/3] xfrm: hold the tunnel device reference across the input path Qihang
2026-10-19 15:55 ` [PATCH net v5 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=20261019153247.89957-1-q.h.hack.winter@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.