From: Simon Horman <horms@kernel.org>
To: Yinhao Hu <dddddd@hust.edu.cn>
Cc: David Heidelberg <david@ixit.cz>, Kees Cook <kees@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Dan Carpenter <error27@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
Samuel Ortiz <sameo@linux.intel.com>,
Michael Thalmeier <michael.thalmeier@hale.at>,
netdev@vger.kernel.org, dzm91@hust.edu.cn,
hust-os-kernel-patches@googlegroups.com
Subject: Re: [PATCH net] nfc: pn533: hold a reference to the request skb during send_frame
Date: Tue, 7 Jul 2026 13:55:11 +0100 [thread overview]
Message-ID: <20260707125511.GD1364329@horms.kernel.org> (raw)
In-Reply-To: <20260626073434.3977525-1-dddddd@hust.edu.cn>
On Fri, Jun 26, 2026 at 12:34:34AM -0700, Yinhao Hu wrote:
> __pn533_send_async() publishes the command and then calls
> dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame
> can be matched to this command: the I2C threaded IRQ runs
> pn533_recv_frame(), which queues cmd_complete_work, and
> pn533_send_async_complete() frees cmd->req with consume_skb().
>
> On the I2C transport, pn533_i2c_send_frame() still dereferences the same
> skb after i2c_master_send() returns, so a completion that races the
> send can free the skb while the transport is still using it.
>
> The request skb is owned by the command object and may be freed by
> command completion at any time after dev->cmd is published, so the
> transport send path must not assume it stays alive. Hold a temporary
> reference to the request skb across the send_frame() call so the
> transport always sees a live skb even if completion races the send.
> Add a pn533_send_cmd_frame() helper and use it from all three send
> paths.
>
> Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from the core implementation")
> Signed-off-by: Yinhao Hu <dddddd@hust.edu.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
There is an AI generated review of this patch available on sashiko.dev.
You may want to consider the issues raised there in the context
of possible follow-up. But I don't think that needs to impede the progress
of this patch.
prev parent reply other threads:[~2026-07-07 12:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 7:34 [PATCH net] nfc: pn533: hold a reference to the request skb during send_frame Yinhao Hu
2026-07-07 12:55 ` Simon Horman [this message]
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=20260707125511.GD1364329@horms.kernel.org \
--to=horms@kernel.org \
--cc=david@ixit.cz \
--cc=dddddd@hust.edu.cn \
--cc=dzm91@hust.edu.cn \
--cc=error27@gmail.com \
--cc=hust-os-kernel-patches@googlegroups.com \
--cc=kees@kernel.org \
--cc=krzk@kernel.org \
--cc=kuba@kernel.org \
--cc=michael.thalmeier@hale.at \
--cc=netdev@vger.kernel.org \
--cc=sameo@linux.intel.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