From: Simon Horman <horms@kernel.org>
To: weir@nebusec.ai
Cc: Simon Horman <horms@kernel.org>,
oe-linux-nfc@lists.linux.dev, netdev@vger.kernel.org,
david@ixit.cz, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, error27@gmail.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
Subject: Re: [PATCH net v2 1/1] net: nfc: fix use-after-free in nfc_get_local_general_bytes
Date: Sat, 5 Sep 2026 16:29:10 +0100 [thread overview]
Message-ID: <20260905152910.94019-1-horms@kernel.org> (raw)
In-Reply-To: <7023ed1e8d7522917d699222d9d5db7135184abb.1788157546.git.rakukuip@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/#/patchset/7023ed1e8d7522917d699222d9d5db7135184abb.1788157546.git.rakukuip@gmail.com?part=1
---
net: nfc: fix use-after-free in nfc_get_local_general_bytes
This commit refactors nfc_get_local_general_bytes to accept a caller-provided
output buffer instead of returning a pointer to local->gb. All callers are
updated to provide their own destination buffers to prevent use-after-free
issues when the local reference count drops to zero.
[ ... ]
> diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
> --- a/net/nfc/nci/core.c
> +++ b/net/nfc/nci/core.c
> @@ -780,26 +780,24 @@ static int nci_set_local_general_bytes(struct nfc_dev *nfc_dev)
> {
> struct nci_dev *ndev = nfc_get_drvdata(nfc_dev);
> struct nci_set_config_param param;
> + u8 gb[NFC_MAX_GT_LEN];
> int rc;
>
> - param.val = nfc_get_local_general_bytes(nfc_dev, ¶m.len);
> - if ((param.val == NULL) || (param.len == 0))
> + nfc_get_local_general_bytes(nfc_dev, gb, sizeof(gb),
> + ¶m.len);
> + if (param.len == 0)
> return 0;
>
> - if (param.len > NFC_MAX_GT_LEN)
> - return -EINVAL;
> -
> + param.val = gb;
> param.id = NCI_PN_ATR_REQ_GEN_BYTES;
>
> - rc = nci_request(ndev, nci_set_config_req, ¶m,
> - msecs_to_jiffies(NCI_SET_CONFIG_TIMEOUT));
> + rc = nci_set_config(ndev, param.id, param.len, param.val);
[Severity: High]
Does replacing nci_request with nci_set_config introduce a locking regression
here?
The original code used nci_request, which acquires ndev->req_lock before
proceeding. The new helper nci_set_config directly calls the unlocked
__nci_request:
net/nfc/nci/core.c:nci_set_config() {
...
return __nci_request(ndev, nci_set_config_req, ¶m,
msecs_to_jiffies(NCI_SET_CONFIG_TIMEOUT));
}
Because __nci_request modifies ndev->req_status and reinitializes
ndev->req_completion, calling it without synchronization can corrupt the
wait queue if another thread is concurrently executing a locked nci_request.
This polling path can be triggered by unprivileged user space via the netlink
NFC_CMD_START_POLL command. Is there a way to restore the req_lock
synchronization for these configuration updates?
> if (rc)
> return rc;
>
> param.id = NCI_LN_ATR_RES_GEN_BYTES;
>
> - return nci_request(ndev, nci_set_config_req, ¶m,
> - msecs_to_jiffies(NCI_SET_CONFIG_TIMEOUT));
> + return nci_set_config(ndev, param.id, param.len, param.val);
> }
prev parent reply other threads:[~2026-09-05 15:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 14:47 [PATCH net v2 0/1] net: nfc: Fix use-after-free in general bytes retrieval Ren Wei
2026-09-01 14:47 ` [PATCH net v2 1/1] net: nfc: fix use-after-free in nfc_get_local_general_bytes Ren Wei
2026-09-05 15:29 ` 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=20260905152910.94019-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=david@ixit.cz \
--cc=dddddd@hust.edu.cn \
--cc=edumazet@google.com \
--cc=error27@gmail.com \
--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 \
--cc=weir@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 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.