CVE-2026-31509

What it actually does

This flaw is a Linux kernel NFC/NCI race-condition and locking-order bug in nci_close_device(). The vulnerable code flushes NFC receive and transmit workqueues while holding ndev->req_lock. Under certain timing, receive work running on rx_wq can follow a path that attempts to acquire the same request lock through nci_request(), creating a circular locking dependency. On affected systems with NFC/NCI support enabled, a local user or local process with access to the relevant NFC interfaces may be able to trigger a kernel deadlock or lockup, causing denial of service. The primary impact is availability loss; the vulnerability is not described as enabling data theft, privilege escalation, or integrity compromise.

Why it matters to the business

Successful exploitation can make an affected Linux system hang, become unstable, or require reboot, which can interrupt workloads, user sessions, embedded devices, kiosks, laptops, or servers that expose NFC/NCI functionality. The risk is lower than remotely exploitable flaws because exploitation requires local access and NFC-related code paths, and current EPSS is very low with no known KEV listing or public exploit maturity. However, systems that depend on continuous uptime or include NFC hardware should prioritize kernel updates because a kernel-level denial of service can cause operational downtime.

How an attack unfolds

An attacker first needs local access to an affected Linux system and a way to interact with NFC/NCI functionality, such as NFC device interfaces, test tools, or applications that exercise the NCI stack. The attacker repeatedly triggers NFC open, close, receive, transmit, or data-exchange paths so that nci_close_device() runs while rx_wq or tx_wq work is still active. In the vulnerable sequence, the close path holds req_lock while flushing workqueues. At the same time, receive work can enter nci_rx_work(), process a data packet, complete a data exchange, destruct a raw NFC socket, deactivate a target, and re-enter nci_request(), which tries to acquire req_lock. This creates a circular dependency and can deadlock the kernel. The expected attacker outcome is a local denial of service through system hang, soft lockup, or an unresponsive NFC/kernel subsystem rather than code execution.

How to fix it

Apply a Linux kernel update from the affected distribution or kernel vendor that includes the NFC/NCI fix for nci_close_device(), specifically the change that releases req_lock before flushing rx_wq. Because no exact fixed package versions were provided, use the latest security-supported kernel available for the operating system release and verify vendor advisories for this CVE. Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce exposure by disabling unused NFC hardware, removing or blacklisting NFC/NCI kernel modules where operationally safe, restricting local shell access, limiting access to NFC device nodes, and preventing untrusted users from running NFC test or fuzzing tools. Mitigation should not be considered equivalent to patching on systems where NFC functionality is required.

How to confirm the fix worked

Confirm the running kernel version is a vendor-fixed build, not merely that a package has been installed. Validate with uname -a, package manager metadata, and the Linux distribution security advisory for the kernel package. If using a custom kernel, verify the source includes the nci_close_device() locking fix that moves rx_wq flushing until after req_lock is released. Confirm whether NFC/NCI is present or loaded by checking loaded modules and kernel configuration for NFC/NCI support. After remediation, reboot and confirm the new kernel is active. For high-assurance validation, run NFC/NCI regression or self-tests under a debug kernel and confirm there are no lockdep circular dependency reports involving nci_close_device, nci_rx_work, nci_request, req_lock, rx_wq, or tx_wq.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel with NFC/NCI support enabled.
2. Identify accessible NFC/NCI device interfaces, NFC sockets, or tooling capable of exercising the NFC stack.
3. Trigger NFC activity involving data exchange, target activation/deactivation, or socket teardown.
4. Race or repeatedly invoke close/deactivation paths so nci_close_device() flushes rx_wq or tx_wq while req_lock is held.
5. Cause rx_wq processing to follow the nci_rx_work() to nci_request() path and attempt to reacquire req_lock.
6. Induce a circular locking dependency, kernel deadlock, lockup, or service interruption.

How to detect it

Review kernel and system logs for evidence of prior triggering. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, lockdep output, hung-task reports, and system watchdog or reboot logs. Look for circular locking dependency warnings, soft lockups, hung tasks, blocked workqueue activity, or stack traces involving the Linux NFC/NCI functions nci_close_device(), nci_rx_work(), nci_rx_data_packet(), nci_data_exchange_complete(), rawsock_destruct(), nfc_deactivate_target(), nci_deactivate_target(), and nci_request(). Also correlate sudden reboots, watchdog resets, or unexplained hangs with local NFC tooling, NFC tests, or processes opening and closing NFC sockets. Because this issue is a denial-of-service race condition rather than malware-driven exploitation, durable file, registry, or network IOCs are unlikely; detection should focus on kernel telemetry and crash/lockup artifacts.

• nci_close_device
• nci_rx_work
• nci_rx_data_packet
• nci_data_exchange_complete
• rawsock_destruct
• nfc_deactivate_target
• nci_deactivate_target
• nci_request
• req_lock
• rx_wq
• tx_wq
• possible circular locking dependency detected
• INFO: task
• blocked for more than
• BUG: soft lockup
• watchdog: BUG: soft lockup
• kernel: NFC
• kernel: nci
• kernel: lockdep
• flush_workqueue

What your security team should do

• Inventory Linux systems with NFC hardware, NFC/NCI kernel modules, or workloads that use NFC functionality.
• Prioritize patching systems where untrusted local users, shared interactive access, kiosks, laptops, or embedded NFC use cases are present.
• Update to the latest vendor-supported Linux kernel containing the NFC/NCI locking fix and reboot to activate it.
• If NFC is not required, disable NFC support or blacklist related modules as a temporary risk-reduction measure.
• Restrict local access and permissions to NFC device interfaces until patching is complete.
• Monitor kernel logs for lockdep, soft lockup, hung task, and NFC/NCI stack traces that may indicate attempted triggering or instability.
• Do not treat the low EPSS and absence from CISA KEV as a reason to ignore patching on availability-sensitive systems.