HIGH Introduced in 3.8
nfc SNL OOB
CVE-2026-90223
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
KernelScan AI8.6HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() 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 < LLCP_HEADER_SIZE), tlv_len 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 "service_name_len = length - 1" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). 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 skb_tail_pointer() 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).
02KernelScan AI Analysis
Risk summary
A nearby NFC device can send a crafted LLCP SNL frame that triggers out-of-bounds reads in the kernel's NFC LLCP parser, without authentication. This can leak kernel memory or crash the kernel, affecting any device with NFC hardware enabled and physically accessible to an attacker.
Vulnerability analysis
The NFC LLCP Service Name Lookup parser walks through type-length-value fields in incoming frames using offsets derived from the frame length, but never checks that those offsets stay within the actual buffer. A short frame causes a length underflow, a TLV with a declared length of zero causes a service-name length to wrap to a huge value, and subsequent string comparisons and lookups read far past the end of the packet data. The fix replaces the offset-based walk with a pointer bounded by the end of the packet data, validates each TLV's declared length before use, and requires SDREQ fields to have at least one byte and SDRES fields to have exactly two. The vulnerable path is reached automatically during NFC LLCP link activation — no authentication is needed — so any device with NFC hardware enabled and an attacker within physical proximity (approximately 4 cm) is at risk.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 3.8 | 5.10.270 | 88b36d36e12c |
| 5.15 | 3.8 | 5.15.221 | 587fc2a5a35b |
| 6.1 | 3.8 | 6.1.188 | f04ac9bf2379 |
| 6.12 | 3.8 | 6.12.110 | 99fdb5c2522f |
| 6.18 | 3.8 | 6.18.52 | 749a9048bf51 |
| 6.6 | 3.8 | 6.6.157 | 02030f95820c |
| 7.2 | 3.8 | 7.2.6 | eeb16fb24cfe |
| mainline | 3.8 | 7.3 | f4c7f37f0ab9 |
| cip/5.10 | 3.8 | 5.10.271-cip78 | 88b36d36e12c |
| cip/6.1 | 3.8 | 6.1.189-cip61 | f04ac9bf2379 |
| cip/6.1-rt | 3.8 | 6.1.189-cip61-rt32 | f04ac9bf2379 |
| cip/6.12 | 3.8 | 6.12.111-cip32 | 99fdb5c2522f |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Fixed in 5.10.271-cip78 |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |
| cip/4.19 | Affected — no CIP fix yet (latest 4.19.325-cip136) |
| cip/4.19-rt | Affected — no CIP fix yet (latest 4.19.325-cip136-rt50) |
| cip/4.4 | Affected — no CIP fix yet (latest 4.4.302-cip115) |
| cip/4.4-rt | Affected — no CIP fix yet (latest 4.4.302-cip115-rt63) |