From: hyunjungg <hj351016@gmail.com>
To: David Heidelberg <david@ixit.cz>
Cc: oe-linux-nfc@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Hyunjung Ko <hj351016@gmail.com>
Subject: [PATCH] nfc: pn533: validate response length before parsing DEP ATR_RES
Date: Thu, 5 Nov 2026 19:39:03 +0900 [thread overview]
Message-ID: <20261105103903.1440114-1-hj351016@gmail.com> (raw)
From: Hyunjung Ko <hj351016@gmail.com>
pn533_poll_dep_complete() and pn533_in_dep_link_up_complete() cast
resp->data to a struct pn533_cmd_jump_dep_response and read its fixed
17-byte header (status, tg, nfcid3t[10], didt, bst, brt, to, ppt)
without first checking that resp->len covers that header.
On a short or truncated response the handlers read bytes beyond the
received frame:
- rsp->status is dereferenced with no minimum-length check;
- for a success status, memcpy(nfc_target.nfcid1, rsp->nfcid3t, 10)
copies 10 bytes from offset 2, so for resp->len < 12 it reads past
the valid response data. Those bytes are then handed to userspace
via nfc_targets_found() (netlink), which can disclose stale buffer
contents.
target_gt_len = resp->len - 17 additionally underflows (it is u8) when
resp->len < 17. That path is mitigated downstream --
nfc_set_remote_general_bytes() -> nfc_llcp_set_remote_gb() rejects the
resulting out-of-range length -- so the subtraction does not by itself
over-read rsp->gt[]; the fixed-field reads above are unguarded
regardless.
A valid ATR_RES always carries the full 17-byte fixed header (the
general bytes, if present, start at offset 17), so reject any response
shorter than sizeof(*rsp) before parsing it. pn533_rf_complete()-style
handlers in this file already length-check resp->len before use (e.g.
the ATR_REQ_GB_OFFSET check in pn533_init_target_complete()).
Found by code review; not reproduced.
Signed-off-by: Hyunjung Ko <hj351016@gmail.com>
---
drivers/nfc/pn533/pn533.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -1309,7 +1309,12 @@ static int pn533_poll_dep_complete(struct pn533 *dev, void *arg,
memset(&nfc_target, 0, sizeof(struct nfc_target));
rsp = (struct pn533_cmd_jump_dep_response *)resp->data;
+ if (resp->len < sizeof(*rsp)) {
+ rc = -EINVAL;
+ goto error;
+ }
+
rc = rsp->status & PN533_CMD_RET_MASK;
if (rc != PN533_CMD_RET_SUCCESS) {
/* Not target found, turn radio off */
@@ -1929,7 +1929,12 @@ static int pn533_in_dep_link_up_complete(struct pn533 *dev, void *arg,
}
rsp = (struct pn533_cmd_jump_dep_response *)resp->data;
+ if (resp->len < sizeof(*rsp)) {
+ rc = -EINVAL;
+ goto error;
+ }
+
rc = rsp->status & PN533_CMD_RET_MASK;
if (rc != PN533_CMD_RET_SUCCESS) {
nfc_err(dev->dev,
next reply other threads:[~2026-11-05 10:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 10:39 hyunjungg [this message]
2026-11-05 10:58 hyunjungg
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=20261105103903.1440114-1-hj351016@gmail.com \
--to=hj351016@gmail.com \
--cc=david@ixit.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oe-linux-nfc@lists.linux.dev \
/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
all inboxes | Powered by JetHome®