From: Joas Antonio dos Santos <joasantonio108@gmail.com>
To: David Heidelberg <david@ixit.cz>
Cc: David S. Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Zhenghang Xiao <kipreyyy@gmail.com>,
Sanghyun Park <sanghyun.park.cnu@gmail.com>,
oe-linux-nfc@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH net 0/5] nfc: fix HCI over NCI and NFCC loopback response handling
Date: Thu, 29 Oct 2026 20:17:35 -0300 [thread overview]
Message-ID: <179331585573.30322.4049957541187612575@gmail.com> (raw)
Patch 1 fixes a regression: since commit 8265a626cc14 ("nfc: nci: fix
double completion race in nci_data_exchange_complete") every data packet
received on an NCI logical connection other than the static RF one is
dropped, because only nci_transceive() sets NCI_DATA_EXCHANGE. That
breaks HCI over NCI (st-nci) and nci_nfcc_loopback() entirely: every
command times out. The commit is in mainline and in the 5.10+ stable
trees.
Patches 2 and 3 fix the handling of the stored response in those two
paths. conn_info->rx_skb is never cleared after the response has been
handed to the caller and freed, and a request can be completed without
a new response (an HCP event or command received on the pipe, or an
unrelated NCI response). The next command then reads, modifies and
returns the freed skb, or dereferences NULL.
Patches 4 and 5 bound the controller supplied pipe ids used as an index
into the pipes[] array in the st21nfca and st-nci load_session
handlers, as pointed out by sashiko.
Testing:
- Patches 1-3 were tested on arm64 QEMU with KASAN, using virtual_ncidev
and a userspace NFCC emulator, plus a test-only ioctl in
virtual_ncidev (not part of this series) that drives
nci_core_conn_create(), nci_hci_dev_session_init(),
nci_hci_get_param() and nci_nfcc_loopback() the way st-nci does.
- Without patch 1, the response to the first ANY_OPEN_PIPE is dropped
and nci_hci_dev_session_init() returns -ETIMEDOUT; with it, session
init and HCP commands complete.
- Without patches 2/3: slab-use-after-free in nci_hci_get_param()
(HCP event instead of a response), null-ptr-deref in
nci_hci_get_param() (no response stored yet), and a
slab-use-after-free on the skb returned by the second
nci_nfcc_loopback(). With them all three return -EPROTO, normal
responses are still returned, and KASAN is quiet.
- tools/testing/selftests/nci passes (8/8) with the series applied.
- Patches 4 and 5 are compile tested only (W=1); I have no ST hardware.
Sanghyun Park's pending "nfc: nci: Fix conn_info use-after-free" v5
touches the same functions in hci.c (it adds a NULL check for rx_skb,
but does not clear it); whichever goes in second will need a rebase.
Joas Antonio dos Santos (5):
nfc: nci: don't drop data received on HCI and loopback connections
nfc: nci: hci: consume the HCP response exactly once
nfc: nci: consume the loopback response exactly once
nfc: st21nfca: validate pipe ids in st21nfca_hci_load_session()
nfc: st-nci: validate pipe ids in st_nci_hci_load_session()
drivers/nfc/st-nci/se.c | 8 ++++
drivers/nfc/st21nfca/core.c | 8 ++++
net/nfc/nci/core.c | 18 ++++++--
net/nfc/nci/data.c | 9 +++-
net/nfc/nci/hci.c | 83 ++++++++++++++++++++++---------------
5 files changed, 87 insertions(+), 39 deletions(-)
--
2.43.0
next reply other threads:[~2026-10-29 23:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 23:17 Joas Antonio dos Santos [this message]
2026-10-29 23:17 ` [PATCH net 2/5] nfc: nci: hci: consume the HCP response exactly once Joas Antonio dos Santos
2026-10-29 23:17 ` [PATCH net 3/5] nfc: nci: consume the loopback " Joas Antonio dos Santos
2026-10-29 23:17 ` [PATCH net 4/5] nfc: st21nfca: validate pipe ids in st21nfca_hci_load_session() Joas Antonio dos Santos
2026-10-29 23:17 ` [PATCH net 1/5] nfc: nci: don't drop data received on HCI and loopback connections Joas Antonio dos Santos
2026-10-29 23:17 ` [PATCH net 5/5] nfc: st-nci: validate pipe ids in st_nci_hci_load_session() Joas Antonio dos Santos
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=179331585573.30322.4049957541187612575@gmail.com \
--to=joasantonio108@gmail.com \
--cc=davem@davemloft.net \
--cc=david@ixit.cz \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kipreyyy@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 \
--cc=sanghyun.park.cnu@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