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 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.