CVE-2026-90223: nfc: llcp: bound SNL TLV parsing to the skb and add length checks
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: bound SNL TLV parsing to the skb and add length checks
nfcllcprecvsnl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed:
- For a short frame (skb->len < LLCPHEADERSIZE), tlvlen underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made "servicenamelen = length - 1" underflow (sizet), driving an out-of-bounds read in the following strncmp() / nfcllcpsockfromsn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check.
A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP.
Walk the TLV list by pointer, bounded by skbtailpointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2).
Found by 0sec automated security-research tooling (https://0sec.ai).
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update kernel code so nfc_llcp_recv_snl() bounds SNL TLV parsing to the skb (walk the TLV list using bounds based on skb_tail_pointer()/linear skb data) and validates each TLV declared length before use; add explicit length checks for SDREQ (length >= 1) and SDRES (exactly 2) to prevent service_name_len underflow and out-of-bounds reads of tlv[2]/tlv[3].
Linux kernel NFC LLCP nfc_llcp_recv_snl() SNL TLV parsing bounds = bounded to skb and with explicit length checks
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel NFC LLCP handling are exposed when they can communicate with a nearby NFC device. The attacker must be within NFC range and able to participate in NFC-DEP communication.
Does exploitation require authentication or manual LLCP setup?
No. A nearby device can reach the vulnerable parsing path without authentication because LLCP link activation occurs automatically after NFC-DEP.
What malformed inputs trigger the unsafe parsing?
Relevant inputs include frames shorter than the LLCP header, truncated TLV headers, TLVs whose declared length exceeds the received buffer, zero-length SDREQ TLVs, and SDRES TLVs not exactly two bytes long.
How can I determine whether a system has the fix?
Check whether the kernel includes the stable commits 88b36d36e12c9ba76decdb580d9c1907c084e587, 587fc2a5a35b41883b22b8f808fe5d345208914b, or f04ac9bf2379f3e2470c400c235eb12f74891bef. The corrected code bounds SNL TLV parsing to the skb data and validates TLV lengths before use.