CVE-2026-80798

nfc: llcp: reject PDUs shorter than the LLCP header

N/A
Published: September 4, 2026 at 03:13 PM UTC
Updated: October 19, 2026 at 09:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes tlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

3.3d646960f7986fefb460a2b062d5ccc8ccfeacc3a
Vendor states this is fixed in 3793d768b40f38bb97265dd5b9a8b8655c4e1b1d (fixed)
Vendor states this is fixed in 95674f506c6376d6722a23144c9acd26609771ed (fixed)
Vendor states this is fixed in a7b9b449f5a5132221fff6adc11a9431ab8cd914 (fixed)
Vendor states this is fixed in ae5f20f5842f440b72d030e3a34fe182dd8eae42 (fixed)
Vendor states this is fixed in d3d90243393c48146911c67fd3792b549d21d9e6 (fixed)
Vendor states this is fixed in e6ec76a68dce04884dfeccfe5a5f0e9f67c0ec82 (fixed)
Vendor states this is fixed in e969e98410051b1ef8cc318bfe0c7e3f24ec766d (fixed)
Vendor states this is fixed in eab47618e282602197db287ecbd1b09d356a2515 (fixed)
Vendor states this is fixed in f36cffea24bf3e2cc29a00d4b51dbcadc087d810 (fixed)
Vendor states this is fixed in 3.3 (unaffected)
Vendor states this is fixed in 5.10.267 (unaffected)
Vendor states this is fixed in 5.15.218 (unaffected)
Vendor states this is fixed in 6.1.185 (unaffected)
Vendor states this is fixed in 6.12.106 (unaffected)
Vendor states this is fixed in 6.18.47 (unaffected)
Vendor states this is fixed in 6.6.154 (unaffected)
Vendor states this is fixed in 7.1.11 (unaffected)
Vendor states this is fixed in 7.2.1 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card