From: Simon Horman <horms@kernel.org>
To: Joas Antonio dos Santos <joasantonio108@gmail.com>
Cc: David Heidelberg <david@ixit.cz>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Fan Wu <fanwu01@zju.edu.cn>,
oe-linux-nfc@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] nfc: st21nfca: complete a pending SE APDU request only once
Date: Sat, 31 Oct 2026 18:25:04 +0000 [thread overview]
Message-ID: <20261031182504.GW257209@horms.kernel.org> (raw)
In-Reply-To: <179332800288.52644.8728400883396719965@gmail.com>
On Thu, Oct 29, 2026 at 11:40:02PM -0300, Joas Antonio dos Santos wrote:
> st21nfca_hci_se_io() stores the netlink callback and its context in
> info->se_info and arms the BWI timer. The request is then completed
> either by st21nfca_se_wt_work(), when the timer expires, or by an
> EVT_TRANSMIT_DATA event on the APDU reader gate. Neither checks that a
> request is still pending, and the callback, se_io_cb(), frees its
> context every time it is called.
>
> So when the secure element answers after the timeout, the response
> calls se_io_cb() again on the context the timeout already freed, and
> frees it a second time. The same happens if the controller sends two
> EVT_TRANSMIT_DATA events for one request. An EVT_TRANSMIT_DATA, or a
> timer armed by EVT_WTX_REQUEST, with no request pending calls the
> callback on the context of an earlier, already completed request, or
> calls a NULL callback if there never was one.
>
> With st21nfca on a virtual phy and an emulated controller answering an
> NFC_CMD_SE_IO request 4 s after it was sent (the default timeout is
> 3.2 s):
>
> BUG: KASAN: slab-use-after-free in se_io_cb+0x2ec/0x334
> Read of size 4 at addr fff00000c5277da0 by task kworker/3:1/59
> Workqueue: events nfc_hci_msg_rx_work
> Call trace:
> se_io_cb+0x2ec/0x334
> st21nfca_apdu_reader_event_received+0x1ec/0x248
> st21nfca_hci_event_received+0xb0/0x300
> nfc_hci_event_received+0xb8/0x30c
> ...
> Freed by task 59:
> kfree+0x214/0x498
> se_io_cb+0x2bc/0x334
> st21nfca_se_wt_work+0x14c/0x1d4
>
> and for an EVT_TRANSMIT_DATA without a request:
>
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> pc : 0x0
> lr : st21nfca_apdu_reader_event_received+0x1ec/0x248
>
> Use bwi_active, which st21nfca_hci_se_io() sets, to tell whether a
> request is pending, and clear it in whichever of the two paths
> completes the request first. The event handler already stops the timer
> and waits for the timeout work before looking at it. Also complete the
> request with the error if sending EVT_SE_END_OF_APDU_TRANSFER fails
> rather than never calling the callback, which leaked the context.
>
> Fixes: 2130fb97fecf ("NFC: st21nfca: Adding support for secure element")
> Cc: stable@vger.kernel.org
> Signed-off-by: Joas Antonio dos Santos <joasantonio108@gmail.com>
> Assisted-by: Yaga Agent HackerSec Claude:claude-opus-5-5
> ---
> Tested on arm64 QEMU with KASAN, with a test-only module that registers
> st21nfca through st21nfca_hci_probe() on a virtual phy (LLC nop) and a
> userspace controller emulator (DEV_UP, ENABLE_SE, SE_IO over netlink).
> Without the patch: slab-use-after-free in se_io_cb() for a late and for
> a duplicated EVT_TRANSMIT_DATA, NULL pointer call for an unsolicited one.
> With it all three are quiet and a normal SE_IO exchange still works.
> Not tested on hardware.
>
> st-nci has the same pattern; Fan Wu's pending "nfc: st-nci: drain SE
> timers before NCI teardown" v2 already makes bwi_active an ownership
> token there, so this only touches st21nfca.
>
> drivers/nfc/st21nfca/se.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
> index 7154bc1d6..4261ed1d9 100644
> --- a/drivers/nfc/st21nfca/se.c
> +++ b/drivers/nfc/st21nfca/se.c
> @@ -264,6 +264,12 @@ static void st21nfca_se_wt_work(struct work_struct *work)
> struct st21nfca_hci_info,
> se_info.timeout_work);
>
> + /* The timer can also be armed by EVT_WTX_REQUEST while no
> + * st21nfca_hci_se_io() is pending.
> + */
> + if (!info->se_info.bwi_active)
> + return;
> +
> info->se_info.bwi_active = false;
Hi Joas,
I'm unsure if it effects the correctness of this fix.
But I am concerned that the use of bwi_active is racy.
>
> if (!info->se_info.xch_error) {
> @@ -383,11 +389,20 @@ int st21nfca_apdu_reader_event_received(struct nfc_hci_dev *hdev,
> case ST21NFCA_EVT_TRANSMIT_DATA:
> timer_delete_sync(&info->se_info.bwi_timer);
> cancel_work_sync(&info->se_info.timeout_work);
> + /* Only complete a pending st21nfca_hci_se_io(), and only once:
> + * the timeout work may already have completed it, and the
> + * callback frees its context.
> + */
> + if (!info->se_info.bwi_active)
> + break;
> +
> info->se_info.bwi_active = false;
> r = nfc_hci_send_event(hdev, ST21NFCA_DEVICE_MGNT_GATE,
> ST21NFCA_EVT_SE_END_OF_APDU_TRANSFER, NULL, 0);
> - if (r < 0)
> + if (r < 0) {
> + info->se_info.cb(info->se_info.cb_context, NULL, 0, r);
> goto exit;
> + }
>
> info->se_info.cb(info->se_info.cb_context,
> skb->data, skb->len, 0);
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-10-31 18:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 2:40 [PATCH net] nfc: st21nfca: complete a pending SE APDU request only once Joas Antonio dos Santos
2026-10-31 18:25 ` Simon Horman [this message]
2026-10-31 19:44 ` Joas Antonio
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=20261031182504.GW257209@horms.kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=david@ixit.cz \
--cc=edumazet@kernel.org \
--cc=fanwu01@zju.edu.cn \
--cc=joasantonio108@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oe-linux-nfc@lists.linux.dev \
--cc=pabeni@redhat.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