From: Ren Wei <weir@nebusec.ai>
To: oe-linux-nfc@lists.linux.dev, netdev@vger.kernel.org, horms@kernel.org
Cc: david@ixit.cz, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, kees@kernel.org,
pengpeng@iscas.ac.cn, raoxu@uniontech.com, rosenp@gmail.com,
dddddd@hust.edu.cn, joe@dama.to, ian.ray@gehealthcare.com,
kuniyu@google.com, linma@zju.edu.cn, vega@nebusec.ai,
rakukuip@gmail.com, weir@nebusec.ai
Subject: [PATCH v3 0/1] net: nfc: fix use-after-free in nfc_get_local_general_bytes
Date: Wed, 9 Sep 2026 13:19:23 +0800 [thread overview]
Message-ID: <cover.1788841682.git.rakukuip@gmail.com> (raw)
From: Luxiao Xu <rakukuip@gmail.com>
This series addresses a use-after-free (UAF) regression introduced by
commit 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by
nfc_llcp_find_local").
In commit 6709d4b7bc2e, nfc_llcp_local_put(local) was added right before
returning local->gb. However, if the reference count drops to zero, the
object is immediately freed, causing callers accessing the returned
pointer to trigger a use-after-free.
Using dynamic allocation (e.g. kmemdup) to copy the buffer was evaluated
in v1, but it led to memory leaks because all callers consistently treat
the returned buffer as borrowed memory and do not free it.
To solve this properly without lifetime issues or leaks, this patch
refactors nfc_llcp_general_bytes() and nfc_get_local_general_bytes() to
take a caller-provided destination buffer and maximum length. The bytes
are safely copied before dropping the reference via nfc_llcp_local_put().
All callers in core and drivers (microread, pn533, pn544, st21nfca,
digital_dep, and nci) are updated accordingly.
---
v3:
- Include <net/nfc/nfc.h> in pn533.h to fix build error in uart.c
caused by undefined NFC_MAX_GT_LEN.
- Restore nci_request() in nci_set_local_general_bytes() to preserve
ndev->req_lock synchronization (avoid unlocked __nci_request() via
nci_set_config()).
v2 Link: https://lore.kernel.org/all/cover.1788157545.git.rakukuip@gmail.com/
v2:
- Use caller-provided output buffers to fix UAF instead of dynamic
allocation (kmemdup), avoiding memory leaks.
Luxiao Xu (1):
net: nfc: fix use-after-free in nfc_get_local_general_bytes
drivers/nfc/microread/microread.c | 6 +++---
drivers/nfc/pn533/pn533.c | 14 ++++++++------
drivers/nfc/pn533/pn533.h | 4 +++-
drivers/nfc/pn544/pn544.c | 7 +++----
drivers/nfc/st21nfca/core.c | 8 ++++----
include/net/nfc/hci.h | 2 +-
include/net/nfc/nfc.h | 3 ++-
net/nfc/core.c | 15 +++++++--------
net/nfc/digital_dep.c | 8 ++++----
net/nfc/llcp_core.c | 17 +++++++++++++----
net/nfc/nci/core.c | 10 +++++-----
net/nfc/nfc.h | 3 ++-
12 files changed, 55 insertions(+), 42 deletions(-)
--
2.43.0
next reply other threads:[~2026-09-09 5:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 5:19 Ren Wei [this message]
2026-09-09 5:19 ` [PATCH v3 1/1] net: nfc: fix use-after-free in nfc_get_local_general_bytes Ren Wei
2026-09-12 10:16 ` Simon Horman
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=cover.1788841682.git.rakukuip@gmail.com \
--to=weir@nebusec.ai \
--cc=davem@davemloft.net \
--cc=david@ixit.cz \
--cc=dddddd@hust.edu.cn \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=ian.ray@gehealthcare.com \
--cc=joe@dama.to \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linma@zju.edu.cn \
--cc=netdev@vger.kernel.org \
--cc=oe-linux-nfc@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=pengpeng@iscas.ac.cn \
--cc=rakukuip@gmail.com \
--cc=raoxu@uniontech.com \
--cc=rosenp@gmail.com \
--cc=vega@nebusec.ai \
/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