From: Steffen Klassert <steffen.klassert@secunet.com>
To: Qihang <q.h.hack.winter@gmail.com>
Cc: <netdev@vger.kernel.org>, David Ahern <dsahern@kernel.org>,
Ido Schimmel <idosch@nvidia.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net 1/2] vti: fix tunnel device use-after-free across async crypto resumption
Date: Mon, 12 Oct 2026 09:54:20 +0200 [thread overview]
Message-ID: <asySLDyakgLAKVdf@secunet.com> (raw)
In-Reply-To: <1791424156.460.8ed76b88c7@gmail.com>
On Thu, Oct 08, 2026 at 01:49:16AM +0000, Qihang wrote:
> All real, and vti6 has the same problems.
>
> The dev_hold()/dev_put() idea assumed the callback runs exactly once
> per skb, which xfrm_input() doesn't guarantee. IPTFS frees the outer
> skb on its own without any callback.
This is a IPTFS bug. If IPTFS frees the skb, it has to make sure
to run the whole destruction path including all the callbacks.
> The early drop when the SA is no
> longer valid happens while family is still AF_UNSPEC, so xfrm_rcv_cb()
> can't find the afinfo and never calls us.
Assigning family before the early drop should fix this.
> And on the success path I'd
> drop the last reference before gro_cells_receive() is done with
> skb->dev.
I think we should unconditionally refcount skb->dev in the
xfrm input path to fix that for now.
next prev parent reply other threads:[~2026-10-12 7:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 9:08 [PATCH net 0/2] vti: fix tunnel device use-after-free across async crypto resumption Qihang
2026-09-30 9:08 ` [PATCH net 1/2] " Qihang
2026-10-04 10:08 ` netdev-bot+sashiko
2026-10-08 1:49 ` Qihang
2026-10-12 7:54 ` Steffen Klassert [this message]
2026-10-12 9:07 ` Qihang
2026-10-12 10:13 ` Steffen Klassert
2026-10-12 11:21 ` Qihang
2026-10-12 11:25 ` Steffen Klassert
2026-09-30 9:08 ` [PATCH net 2/2] vti6: " Qihang
2026-10-04 10:08 ` netdev-bot+sashiko
2026-09-30 9:13 ` [PATCH net 0/2] vti: " 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=asySLDyakgLAKVdf@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--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=q.h.hack.winter@gmail.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.