Look up another CVE · open CVE-2026-90223 in the interactive tracker
CVE-2026-90223
nfc: llcp: bound SNL TLV parsing to the skb and add length checks
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem net/nfc. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90223 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/nfc/llcp_core.c
- What this is
- NFC SUBSYSTEMMAINTAINERS section matched on net/nfc/ · oe-linux-nfc@lists.linux.dev · Maintained
- Kernel module
- nfc
Check it on the machine
grep -w CONFIG_NFC /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w nfcPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_NFC
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.41%, higher than 34.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/nfc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.8 | 5.10.270 | 88b36d36e12c |
| 3.8 | 5.15.221 | 587fc2a5a35b |
| 3.8 | 6.1.188 | f04ac9bf2379 |
| 3.8 | 6.6.157 | 02030f95820c |
| 3.8 | 6.12.110 | 99fdb5c2522f |
| 3.8 | 6.18.52 | 749a9048bf51 |
| 3.8 | 7.2.6 | eeb16fb24cfe |
| 3.8 | 7.3 | f4c7f37f0ab9 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- A nearby NFC-DEP peer supplies the malformed bytes in an LLCP SNL PDU (ptype LLCP_PDU_SNL, DSAP/SSAP LLCP_SAP_SDP). nfc_tm_data_received() or the initiator nfc_llcp_recv() callback delivers that skb through __nfc_llcp_recv() and nfc_llcp_rx_skb() into nfc_llcp_recv_snl(), which walks attacker-controlled SDREQ/SDRES TLVs. NFC is radio-range, so Adjacent.
- AC:LAttack complexity, low
- The attacker fully controls the SNL payload, including each TLV type and u8 length. An SDREQ with length 0 or 15, or a declared length past the remaining skb, hits the missing header/value checks in nfc_llcp_recv_snl() deterministically, with no race or heap layout the attacker cannot set.
- PR:NPrivileges required, none
- nfc_llcp_recv_snl() only rejects PDUs whose DSAP/SSAP are not LLCP_SAP_SDP; it does not require LLCP CONNECT, SDP credentials, or any host account. After nfc_dep_link_is_up(), an unauthenticated NFC-DEP peer can send SNL immediately.
- UI:NUser interaction, none
- nfc_tm_activated() calls nfc_dep_link_is_up() automatically when protocol is NFC_PROTO_NFC_DEP_MASK, after which nfc_tm_data_received() hands DEP payloads to LLCP. The attacker triggers the SNL parse with their own frames; no extra victim click, mount, or dialog is required.
- S:UScope, unchanged
- nfc_llcp_recv_snl() over-reads kernel memory adjacent to the received skb in the LLCP receive path. That stays inside the host kernel's security authority; there is no VM, IOMMU, or sandbox boundary crossed.
- C:LConfidentiality impact, low
- A short SDREQ with length==15 makes strncmp(service_name, "urn:nfc:sn:sdp", 14) read up to 14 bytes past the skb, and length==0 uses out-of-bounds tlv[2] as the tid echoed by nfc_llcp_build_sdres_tlv(). nfc_llcp_sock_from_sn() memcmp is gated on matching socket name length, so this is a small bounded leak, not an arbitrary read.
- I:NIntegrity impact, none
- The SNL walker only reads past the skb; it does not write past it. The SDRES path assigns tlv[3] into an existing pending nfc_llcp_sdp_tlv->sap on a tid match, which is an in-object protocol field a well-formed SDRES can already set, not a kernel write primitive.
- A:HAvailability impact, high
- nfc_llcp_recv_snl() can read tlv[0]/tlv[1] when fewer than two bytes remain, and strncmp()/tlv[2] past the skb tail. Those over-reads can fault on an unmapped page or KFENCE guard and oops the kernel.