CVE-2026-23150: Linux Kernel Race Condition Vulnerability

CVE-2026-23150 Overview

CVE-2026-23150 is a memory leak vulnerability in the Linux kernel's Near Field Communication (NFC) Logical Link Control Protocol (LLCP) subsystem. The flaw resides in the nfc_llcp_send_ui_frame() function, where a race condition between frame transmission and socket teardown allows socket buffers (sk_buff) and related NFC structures to leak from kernel memory. The vulnerability was reported via the syzbot fuzzer, which observed unreferenced allocations of nfc_llcp_sock, sk_buff, and nfc_dev objects. A local user with the ability to open NFC sockets can repeatedly trigger the race to exhaust kernel memory.

Critical Impact
Local attackers can trigger sustained kernel memory leaks in the NFC LLCP subsystem, leading to resource exhaustion and potential denial of service on affected Linux systems.

Affected Products

Linux Kernel (multiple stable branches prior to fix)
Linux Kernel 6.19 release candidates (rc1 through rc7)
Linux distributions shipping the affected kernel with CONFIG_NFC enabled

Discovery Timeline

2026-02-14 - CVE-2026-23150 published to NVD
2026-03-17 - Last updated in NVD database

Technical Details for CVE-2026-23150

Vulnerability Analysis

The vulnerability is a classic memory leak [CWE-401] caused by missing synchronization between two concurrent kernel paths. The nfc_llcp_send_ui_frame() function allocates a socket buffer and queues it onto local->tx_queue for transmission. In parallel, local_cleanup() calls nfc_llcp_socket_release() to mark sockets with -ENXIO and then invokes skb_queue_purge() to drain local->tx_queue during destruction of the nfc_llcp_local structure.

Because the two paths do not coordinate on local->tx_queue.lock, a thread executing nfc_llcp_send_ui_frame() can queue a freshly allocated sk_buff onto the transmit queue immediately after local_cleanup() has already purged it. The queued buffer is never drained again, leaving the sk_buff, the parent socket allocation from sk_alloc(), and associated NFC structures permanently leaked. Each successful race leaks approximately 1024 bytes from the socket allocation plus 240 bytes per sk_buff, as shown in the kmemleak traces from the syzbot report.

Root Cause

The root cause is the absence of mutual exclusion around the producer-consumer relationship for local->tx_queue. The patch resolves this by holding local->tx_queue.lock and checking list_empty(&local->list) before queuing the new PDU. If the nfc_llcp_local instance has already been unlinked from llcp_devices, the send path drops the skb instead of enqueueing it.

Attack Vector

Exploitation requires local access and the ability to create NFC sockets via the AF_NFC socket family. An attacker repeatedly races socket transmission against NFC device teardown to accumulate leaked allocations. The CWE-401 memory leak path does not yield code execution or information disclosure but degrades system stability over time. The vulnerability manifests in the LLCP send path; refer to the upstream commits in the kernel.org stable tree for the exact code modifications.

Detection Methods for CVE-2026-23150

Indicators of Compromise

Kernel log messages such as llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) indicating ENXIO from a released LLCP socket.
kmemleak reports flagging unreferenced allocations originating from sk_prot_alloc, nfc_llcp_sock_alloc, or __alloc_skb under the NFC code paths.
Steady, unexplained growth of Slab and SUnreclaim values in /proc/meminfo on hosts with NFC enabled.

Detection Strategies

Enable CONFIG_DEBUG_KMEMLEAK on test systems and scan /sys/kernel/debug/kmemleak for backtraces referencing nfc_llcp_sock_alloc or llcp_sock_create.
Audit running kernels for vulnerable versions using uname -r and compare against the fixed commits published on git.kernel.org.
Monitor processes that open AF_NFC sockets via auditd rules on the socket() syscall with a0=39 (AF_NFC family).

Monitoring Recommendations

Track kernel memory usage trends with telemetry pipelines and alert on sustained slab growth without corresponding workload changes.
Collect dmesg and journald events for NFC subsystem warnings, particularly PDU allocation failures.
Inventory systems where the NFC stack is loaded but unused, since these are prime candidates for module blacklisting.

How to Mitigate CVE-2026-23150

Immediate Actions Required

Apply the upstream kernel patches referenced in the vendor advisories before exposing systems to untrusted local users.
If NFC functionality is not required, blacklist the nfc and nfc_llcp kernel modules to remove the attack surface entirely.
Restrict access to systems with NFC hardware to trusted users, since exploitation requires local socket creation.

Patch Information

The Linux kernel maintainers released the fix across multiple stable branches. Commits include 165c34fb6068, 3098e5c8af0f, 61858cbce6ca, 65e976e1f474, 6734ff1ac6be, ab660cb8e17a, and f8d002626d43. The fix introduces locking on local->tx_queue.lock and a list_empty(&local->list) guard in nfc_llcp_send_ui_frame(). Distribution-supplied kernels should be updated to versions that incorporate these commits; consult your vendor's security advisory for the corresponding package release.

Workarounds

Unload the NFC modules where not needed: modprobe -r nfc_llcp nfc.
Add install nfc /bin/true to /etc/modprobe.d/blacklist-nfc.conf to prevent automatic loading on boot.
Limit which users can create AF_NFC sockets via seccomp profiles or SELinux/AppArmor policies on multi-tenant hosts.

bash

# Configuration example: prevent the vulnerable NFC LLCP stack from loading
cat <<'EOF' | sudo tee /etc/modprobe.d/disable-nfc.conf
blacklist nfc
blacklist nfc_llcp
install nfc /bin/true
install nfc_llcp /bin/true
EOF

sudo modprobe -r nfc_llcp nfc 2>/dev/null || true
sudo update-initramfs -u