CVE-2026-64010

What it actually does

This is a Linux kernel use-after-free race in the NFC Logical Link Control Protocol (LLCP) connection handling path. When an LLCP connection-complete packet is received, nfc_llcp_recv_cc() can move a socket between internal connection lists without holding the socket lock while a concurrent socket release path, llcp_sock_release(), may be unlinking and freeing the same socket. If the race is won, a freed socket object can be reinserted into a live kernel list, creating kernel memory corruption. Successful exploitation could cause a kernel crash or, in a more advanced exploit, potentially enable arbitrary code execution in kernel context with full confidentiality, integrity, and availability impact. The attack vector is adjacent rather than internet-routable: an attacker generally needs NFC proximity to the target and a target system with NFC/LLCP support enabled.

Why it matters to the business

Systems with enabled NFC support could be crashed or potentially compromised by an attacker in close physical/NFC range. The most likely operational impact is denial of service through a kernel panic or device instability, but the severity is high because kernel memory corruption can sometimes be developed into full system compromise. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS at 0.00255, and has no reported public exploit maturity, so urgency is highest for laptops, kiosks, mobile/embedded Linux devices, payment-adjacent systems, and other assets where NFC is enabled or exposed.

How an attack unfolds

An attacker positions an NFC-capable device within NFC communication range of a vulnerable Linux system with NFC LLCP enabled. The attacker initiates or manipulates an LLCP connection and sends timing-sensitive connection-complete traffic while the target is concurrently closing or releasing the associated LLCP socket. By repeatedly forcing the connection state transition to race against socket release, the attacker attempts to make nfc_llcp_recv_cc() operate on a socket object that llcp_sock_release() has already unlinked and released. If successful, the kernel may link freed memory back into active socket lists, leading to memory corruption. In a basic attack this may crash the kernel; in a sophisticated attack, the corrupted object state could potentially be shaped to gain kernel-level execution or privilege.

How to fix it

Apply a Linux kernel update that includes the NFC LLCP fix for the locking defect in nfc_llcp_recv_cc(). The fix holds the socket lock during the connection state transition and verifies that the socket is still hashed before moving it between LLCP socket lists. Because no exact fixed package versions were provided, use vendor advisories for the relevant Linux distribution, appliance, embedded platform, or kernel branch to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling NFC functionality, disabling or unloading NFC-related kernel modules where operationally safe, blacklisting NFC modules, disabling NFC hardware in firmware/BIOS or device policy, and restricting physical proximity to affected systems. Mitigations should be treated as temporary because they reduce attack surface but do not correct the kernel race condition.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version or vendor kernel package includes the upstream NFC LLCP locking fix for nfc_llcp_recv_cc(). Validate the running kernel, not only the installed package, because a reboot is typically required after kernel updates. Check whether NFC support is enabled by reviewing kernel configuration, loaded modules, device inventory, and NFC service state. On Linux systems, useful checks include reviewing uname -a, distribution package metadata, /boot/config-* for NFC-related options, lsmod for NFC-related modules, and dmesg for NFC device initialization. If NFC is not required, confirm that NFC modules are not loaded and NFC hardware is disabled. For assurance testing, exercise NFC functionality after patching and confirm that no kernel warnings, KASAN reports, oopses, or panics occur around LLCP connection setup or teardown.

Typical attack path

1. Identify a Linux target with NFC hardware and NFC/LLCP kernel support enabled.
2. Move an attacker-controlled NFC device into communication range of the target.
3. Initiate LLCP connection activity against the target NFC stack.
4. Send crafted or carefully timed LLCP connection-complete traffic while triggering connection teardown behavior.
5. Repeat the race until the vulnerable socket state transition collides with socket release.
6. Cause kernel memory corruption, typically resulting in a crash, or attempt further exploitation for kernel-level control.

How to detect it

Detection of prior exploitation is difficult because the vulnerability is a race condition in kernel memory management and may leave only crash artifacts. Review kernel logs, persistent journal entries, crash dumps, pstore/ramoops records, kdump/vmcore data, and endpoint telemetry for NFC-related kernel oopses, panics, KASAN reports, or traces referencing nfc_llcp_recv_cc(), llcp_sock_release(), LLCP socket state transitions, or list corruption. Correlate crashes with physical access windows, NFC device proximity events where logged, sudden loading of NFC-related modules, or repeated NFC connection attempts. On systems with kernel sanitizers or hardened crash reporting, search for use-after-free, slab corruption, general protection faults, NULL pointer dereferences, and list_add/list_del corruption involving the NFC subsystem. Absence of these artifacts does not prove non-exploitation, especially if logs are volatile or the system rebooted after a panic.

• nfc_llcp_recv_cc
• llcp_sock_release
• BUG: KASAN: use-after-free
• use-after-free in nfc_llcp_recv_cc
• general protection fault
• kernel BUG at net/nfc/llcp
• net/nfc/llcp_core.c
• list_add corruption
• list_del corruption
• kernel panic - not syncing
• Unable to handle kernel paging request
• Oops:
• NFC: LLCP
• nfc: llcp
• llcp_sock
• /sys/module/nfc
• /proc/modules

What your security team should do

• Prioritize patching systems with NFC hardware enabled, especially laptops, kiosks, mobile/embedded Linux devices, public-access systems, and systems used in sensitive workflows.
• Inventory Linux assets for NFC capability and determine whether NFC LLCP is enabled, loaded, or required.
• Apply vendor-supplied kernel updates and reboot into the fixed kernel; verify the active kernel after reboot.
• Disable NFC support where it is not business-critical, including kernel modules, services, hardware interfaces, or firmware settings where available.
• Increase monitoring for kernel crashes, oops reports, KASAN use-after-free findings, and NFC stack errors on systems with NFC enabled.
• Treat unexplained kernel panics involving nfc_llcp_recv_cc(), llcp_sock_release(), or NFC LLCP list handling as potential exploitation or attempted exploitation.
• Because there is no KEV listing, no known ransomware use, and low EPSS, schedule broad remediation through normal kernel patch cycles while accelerating remediation for exposed NFC-enabled assets.