CVE-2026-64011

What it actually does

This is a local use-after-free vulnerability in the Linux kernel NFC Logical Link Control Protocol (LLCP) socket release path. When an LLCP socket is released while still in a connecting state, the kernel may unlink it from the wrong internal socket list, leaving stale list pointers and allowing freed kernel memory to be referenced later. A local user with access to the affected NFC socket functionality may be able to trigger memory corruption in kernel context, potentially causing denial of service or, with a reliable exploit, local privilege escalation to kernel-level execution.

Why it matters to the business

Successful exploitation could allow a user or compromised low-privilege process on an affected Linux system to crash the system or gain elevated privileges. The practical risk is highest on systems where NFC kernel support is enabled and reachable by local users, such as laptops, mobile/embedded Linux devices, kiosks, point-of-sale devices, and systems using NFC hardware. The vulnerability is not known to be exploited in the wild, is not listed in CISA KEV, and has a low EPSS score, so urgency is lower than for actively exploited remote vulnerabilities; however, kernel privilege-escalation flaws should still be remediated through normal kernel patch cycles.

How an attack unfolds

An attacker first needs local code execution as an unprivileged or low-privileged user on a Linux system with the vulnerable NFC LLCP kernel code available. They interact with the NFC socket interface and create an LLCP socket that enters the connecting state. The attacker then forces the socket release path while the socket remains on the connecting list. Because the vulnerable code unconditionally removes the socket from the local sockets list instead of the correct connecting list, kernel list state can become inconsistent and a freed socket object may be referenced later. In the simplest case this results in a kernel crash or panic. A more capable attacker may shape heap allocations around the freed object and attempt to turn the use-after-free into controlled kernel memory corruption, enabling privilege escalation.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix for the NFC LLCP socket release logic. Because no specific affected product list or fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, device vendor, or kernel supplier. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the old kernel remains running. As a mitigation where NFC is not required, disable NFC support, prevent loading of NFC-related kernel modules, and restrict local access to NFC socket functionality where possible. On systems that support module controls, consider blacklisting NFC modules such as nfc, llcp, and hardware-specific NFC drivers if they are not operationally needed.

How to confirm the fix worked

Confirm the running kernel version is the patched version supplied by the operating system or device vendor, not just that an updated package is installed. Verify after reboot with commands such as `uname -a` and distribution package tooling. Check whether NFC support is present or loaded using commands such as `lsmod | grep -i nfc`, `modinfo nfc`, and inspection of `/proc/net/` or socket availability where applicable. If NFC is not required and has been disabled, validate that NFC-related modules are not loaded and cannot be auto-loaded by an unprivileged user. For source-based or custom kernels, verify that the LLCP socket release logic checks the socket state and unlinks the socket from the correct list when the socket is still connecting.

Typical attack path

1. Gain local code execution on a Linux host with the vulnerable kernel and NFC/LLCP support enabled.
2. Confirm that NFC socket functionality is available to the local user or reachable through an enabled kernel module.
3. Create an NFC LLCP socket and drive it into the connecting state.
4. Release or close the socket while it remains on the connecting list.
5. Trigger subsequent kernel operations that reference the stale or incorrectly unlinked socket object.
6. Use the resulting memory corruption to crash the kernel or attempt privilege escalation.

How to detect it

Review host and centralized system logs for evidence of kernel memory corruption or crashes involving NFC LLCP code. Useful sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, kernel crash dumps, pstore logs, kdump/vmcore artifacts, and EDR telemetry that captures kernel panic or privilege-escalation behavior. Look for stack traces referencing `llcp_sock_release`, NFC LLCP socket handling, list corruption, use-after-free, KASAN reports, general protection faults, kernel BUG/Oops messages, or sudden reboots following local NFC socket activity. There are no public exploit-specific indicators or known threat actor campaigns associated with this vulnerability, so detection should focus on behavioral artifacts: anomalous local processes interacting with NFC sockets, crashes in the NFC subsystem, unexpected loading of NFC modules, and kernel memory-corruption reports. If a suspected crash is found, preserve the running and installed kernel versions, module list, crash dump, relevant process accounting/audit logs, and timestamps around module loading or NFC socket usage.

• llcp_sock_release
• KASAN: use-after-free
• use-after-free in llcp_sock_release
• nfc: llcp
• NFC LLCP
• kernel BUG
• kernel Oops
• general protection fault
• list_del corruption
• list_add corruption
• BUG: unable to handle kernel paging request
• RIP: llcp_sock_release
• Call Trace: llcp_sock_release
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/module/nfc
• /sys/module/llcp

What your security team should do

• Prioritize patching systems where local users, untrusted workloads, kiosks, shared desktops, containers with broad host access, or embedded applications can execute code on the host.
• Patch or upgrade to the vendor-fixed kernel and reboot systems to ensure the fixed kernel is active.
• Identify systems with NFC hardware, NFC kernel modules, or NFC-related services enabled; focus validation on those systems first.
• Disable or blacklist NFC kernel modules on servers and devices that do not require NFC functionality.
• Monitor kernel logs for crashes, KASAN reports, or stack traces referencing NFC LLCP socket handling, especially `llcp_sock_release`.
• Treat unexpected kernel panics or NFC-related kernel memory-corruption logs as potential exploitation attempts and preserve logs, crash dumps, and kernel versions for forensic review.
• Because the vulnerability is not currently in KEV and has low EPSS, handle through an expedited but risk-based kernel maintenance process rather than emergency internet-facing remediation.