CVE-2025-71079 in Linux
Summary
by MITRE • 01/13/2026
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write
A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex.
The problematic lock order is:
Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lock
Thread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutex
This creates a classic ABBA deadlock scenario.
Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock.
This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free.
The similar lock ordering in nfc_register_device() (device_lock -> rfkill_global_mutex via rfkill_register) is safe because during registration the device is not yet in rfkill_list, so no concurrent rfkill operations can occur on this device.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/31/2026
The vulnerability described in CVE-2025-71079 represents a critical deadlock condition affecting the Linux kernel's NFC (Near Field Communication) subsystem. This issue manifests when the kernel attempts to unregister an NFC device while another thread is simultaneously executing rfkill operations, creating a classic ABBA deadlock scenario. The vulnerability specifically impacts the interaction between two core kernel components: the NFC device management framework and the rfkill subsystem responsible for managing wireless device kill switches. The deadlock occurs due to improper lock ordering that violates fundamental concurrency principles in kernel space programming.
The technical flaw stems from a specific lock ordering inversion pattern that violates the principle of consistent lock acquisition order. In the problematic execution flow, Thread A executing rfkill_fop_write() first acquires the rfkill_global_mutex and then attempts to acquire device_lock, while Thread B executing nfc_unregister_device() first acquires device_lock and then attempts to acquire rfkill_global_mutex. This inversion creates a circular wait condition where each thread holds a lock that the other requires, leading to system-wide deadlock. The vulnerability is classified under CWE-362: Concurrent Execution Using Locks, which specifically addresses issues related to improper lock ordering and concurrent access patterns in multi-threaded environments. The ATT&CK framework would categorize this under T1499.004: Endpoint Denial of Service, as this vulnerability can result in complete system unresponsiveness.
The operational impact of this vulnerability extends beyond simple system hangs, potentially affecting any NFC-enabled device functionality within the Linux kernel environment. When the deadlock occurs, it prevents proper device cleanup and registration operations, which can lead to resource leaks, device unresponsiveness, and in severe cases, complete system freeze. This affects embedded systems, mobile devices, and servers that rely on NFC functionality, particularly those implementing wireless kill switch mechanisms. The vulnerability is particularly concerning because it can be triggered through normal device operation sequences, making it difficult to predict and prevent in production environments. The fix implemented addresses this by restructuring the locking pattern to ensure that rfkill cleanup operations occur outside of the device_lock critical section, thereby eliminating the circular dependency.
The mitigation strategy implemented in the kernel fix follows established best practices for avoiding lock ordering inversions in kernel space programming. By moving rfkill_unregister() and rfkill_destroy() operations outside the device_lock scope and storing the rfkill pointer in a local variable before releasing the lock, the fix ensures that cleanup operations can proceed without blocking the device management thread. This approach is safe because the rfkill subsystem maintains proper synchronization through the rfkill_global_mutex, which ensures that rfkill_unregister() waits for any ongoing callback operations to complete before proceeding. The solution also properly coordinates with device_del() operations to prevent use-after-free conditions, maintaining memory safety throughout the cleanup process. This fix aligns with kernel development standards and addresses the specific requirements outlined in the Linux kernel's locking guidelines, ensuring that concurrent access patterns maintain proper ordering and prevent deadlock scenarios. The implementation also preserves the existing safety guarantees during device registration, where the reverse lock ordering is safe due to the device not yet being registered in the rfkill list.