From: <steffen-ai@klassert.de>
To: "Qi Tang" <tpluszz77@gmail.com>
Cc: <steffen.klassert@secunet.com>, <netdev@vger.kernel.org>,
<herbert@gondor.apana.org.au>, <davem@davemloft.net>,
<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
<horms@kernel.org>, <stable@vger.kernel.org>,
<steffen@klassert.de>
Subject: Re: [PATCH net] xfrm: hold skb->dev across async IPv6 transport reinject
Date: Fri, 20 Mar 2026 08:32:12 +0000 [thread overview]
Message-ID: <189e7f89b082031f.2492293c508f2522.8ac0d063cc181f1a@nbg3-de> (raw)
Subject: Re: [PATCH net] xfrm: hold skb->dev across async IPv6 transport reinject
In-Reply-To: <20260320073023.21873-1-tpluszz77@gmail.com>
To: Qi Tang <tpluszz77@gmail.com>
Cc: netdev@vger.kernel.org, steffen.klassert@secunet.com, herbert@gondor.apana.org.au, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, stable@vger.kernel.org
The fix looks correct. A few comments:
1. The approach of holding a netdev reference at enqueue time and
releasing it after async reinject properly addresses the UAF window.
The ordering in xfrm_trans_reinject() is key - caching the dev
pointer before calling finish() avoids touching skb->cb after a
callback that may consume/free the skb.
2. One minor note: the net tree generally prefers netdev_hold() /
netdev_put() for reference tracking, but dev_hold() / dev_put()
is functionally equivalent here.
3. The BUILD_BUG_ON() in xfrm_trans_queue_net() will catch any cb
size overflow, so that's covered.
No functional issues observed.
Reviewed-by: Steffen Klassert <steffen.klassert@secunet.com>
Model: openai-codex/gpt-5.3-codex
next reply other threads:[~2026-03-20 8:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 8:32 steffen-ai [this message]
2026-03-20 8:37 ` [PATCH net] xfrm: hold skb->dev across async IPv6 transport reinject Steffen Klassert
-- strict thread matches above, loose matches on Subject: below --
2026-03-20 7:30 Qi Tang
2026-03-20 7:44 ` Steffen Klassert
2026-03-26 12:41 ` Qi Tang
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=189e7f89b082031f.2492293c508f2522.8ac0d063cc181f1a@nbg3-de \
--to=steffen-ai@klassert.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=steffen@klassert.de \
--cc=tpluszz77@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox