nfc: llcp: fix SNL PDU size truncation in nfc_llcp_allocate_snl()
Subsystems (4)
PATCH 1/1 nfc: llcp: fix SNL PDU size truncation in nfc_llcp_allocate_snl()
From: Linkui Xiao <[email protected]>
nfc_llcp_allocate_snl() sums the requested TLV payload length into a u16 variable before passing it to alloc_skb(), but its tlv_length argument is a size_t and callers pass a length bounded only by the size of the netlink message that produced it.
nfc_genl_llc_sdreq() walks the nested NFC_ATTR_LLC_SDP attributes of a GENL_ADMIN_PERM request, builds one SDREQ TLV per attribute and sums their lengths into the size_t tlvs_len. Each URI is capped at U8_MAX - 4 bytes by nfc_sdp_genl_policy, so every TLV fits in its u8 tlv_len, but nothing caps the number of attributes, so tlvs_len can exceed U16_MAX.
When it does, the u16 accumulator wraps and alloc_skb() returns a buffer that is far too small. nfc_llcp_send_snl_sdreq() then calls skb_put_data() once per TLV and writes all tlvs_len bytes into it, which trips skb_over_panic() and panics the machine.
Use size_t for the accumulated size so that it can no longer wrap before the allocation. alloc_skb() takes an unsigned int, which is still wide enough for any length a netlink message can carry.
--- net/nfc/llcp_commands.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/nfc/llcp_commands.c +1 -1
@@ -542,7 +542,7 @@ static struct sk_buff *nfc_llcp_allocate_snl(struct nfc_llcp_local *local, {struct sk_buff *skb;struct nfc_dev *dev; -u16 size =0 ; +size_t size =0 ;if (local ==NULL )return ERR_PTR (-ENODEV );
Signature · 1 line
2.25.1
[email protected]
AI reviewThis is an automated message. This series looks like a fix, but its commit messages seem to be missing some information:
Hi!
This is an automated message. This series looks like a fix, but its commit messages seem to be missing some information:
- Whether the issue was actually triggered, or is only theoretical (e.g. found by LLM and not proven at runtime). If it was triggered please include the symptoms, like the stack trace or kernel messages.
Please do not repost the series just to address the above. Instead, reply to this email with the missing information, so that reviewers can take it into account. If the series needs another revision for other reasons, please include the information in the commit messages then.
The evaluation is done by an LLM so it may be wrong, if you think that is the case please reply and explain.