Cloudanix VulnDB

CVE-2026-80798

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A wireless communication feature in some devices could be tricked by a nearby gadget into crashing the system or leaking memory contents.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Missing length validation in Linux kernel NFC LLCP receive path allows short PDUs to trigger skb length subtraction wrap-around, resulting in out-of-bounds read during TLV parsing in nfc_llcp_rx_skb and __nfc_llcp_recv.

Why it matters to the business

Nearby attackers can cause kernel crashes or memory disclosure on systems with NFC support, leading to device instability, potential data leaks, and downtime for embedded, mobile, or IoT deployments that rely on near-field communication.

How an attack unfolds

An attacker brings a malicious NFC device into proximity, allowing automatic LLCP link activation after NFC-DEP; a crafted PDU shorter than the two-byte header is sent, bypassing checks in nfc_llcp_ptype/dsaps/saps and causing the receive worker to read past the buffer.

How to fix it

Apply the upstream kernel patch that adds a pskb_may_pull guard for header length in __nfc_llcp_recv before any header parsing or TLV walk; update to a kernel release containing the fix for the NFC LLCP receive path.

How to confirm the fix worked

Inspect the __nfc_llcp_recv function for the added length check using pskb_may_pull; reproduce with short PDUs via virtual NCI or similar test harness to confirm no out-of-bounds access occurs.

Typical attack path

  1. Bring malicious NFC device within range of target
  2. Trigger NFC-DEP link activation to establish LLCP session
  3. Transmit LLCP PDU shorter than LLCP_HEADER_SIZE bytes
  4. Trigger out-of-bounds memory read in kernel receive path

How to detect it

Review kernel logs and dmesg for KFENCE or KASAN reports referencing nfc_llcp or LLCP header processing; inspect NFC receive paths for evidence of short skb handling or abnormal frame lengths.

What your security team should do

  • Disable NFC kernel modules or hardware if NFC functionality is not required
  • Prioritize kernel updates containing the LLCP header length validation fix
  • Monitor NFC-related kernel logs and oops reports for signs of malformed frame handling

The record

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 packages

Ecosystem Package Introduced Fixed