Cloudanix VulnDB

CVE-2026-98482

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's near-field communication code could let attackers read leftover memory contents by sending specially crafted short messages.

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

What it actually does

The nfc_llcp_recv_hdlc function reads the sequence byte from skb->data[2] via nfc_llcp_ns/nfc_llcp_nr before verifying sufficient PDU length with pskb_may_pull, allowing a two-byte truncated I/RR/RNR frame to consume one byte of uninitialized skb tailroom as N(R)/N(S) sequence state.

Why it matters to the business

Kernel memory corruption in the NFC LLCP receive path can lead to undefined behavior or information disclosure on systems handling near-field communication traffic, increasing exposure for devices that rely on this subsystem.

How an attack unfolds

An attacker crafts and sends a truncated two-byte I, RR or RNR PDU over NFC LLCP. The receive handler performs the sequence-byte read before the length guard, pulling uninitialized memory into protocol state that a well-formed PDU could otherwise control.

How to fix it

Apply the upstream fix that adds an explicit pskb_may_pull check before reading the sequence byte; rebuild and deploy the patched kernel image.

How to confirm the fix worked

Confirm the presence of the pskb_may_pull guard in nfc_llcp_recv_hdlc and that nfc_llcp_recv_agf continues to reject undersized frames; exercise the NFC LLCP path with truncated PDUs to verify no uninitialized read occurs.

Typical attack path

  1. Establish an NFC LLCP link with the target
  2. Transmit a deliberately truncated two-byte I/RR/RNR PDU
  3. Trigger nfc_llcp_recv_hdlc to read the sequence byte from uninitialized memory
  4. Observe resulting kernel behavior or memory disclosure

How to detect it

Review kernel logs for NFC LLCP receive-path warnings or oopses; inspect skb allocation and pull patterns around nfc_llcp_recv_hdlc in crash dumps or with dynamic tracing.

What your security team should do

  • Prioritize kernel updates on any system exposing NFC LLCP
  • Disable NFC interfaces where not required
  • Monitor for new kernel releases containing the referenced length-check commit

The record

In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() nfc_llcp_recv_hdlc() reads the sequence byte skb->data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control. Guard the read with pskb_may_pull(), as commit 95674f506c63 ("nfc: llcp: reject PDUs shorter than the LLCP header") did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.

Affected packages

Ecosystem Package Introduced Fixed