CVE-2025-71079
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-13

Last updated on: 2026-03-25

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-13
Last Modified
2026-03-25
Generated
2026-05-06
AI Q&A
2026-01-14
EPSS Evaluated
2026-05-05
NVD
CVE-2025-71079
Affected Vendors & Products
Showing 20 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.16
linux linux_kernel From 4.4.293 (inc) to 4.5 (exc)
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.13 (inc) to 6.18.4 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.120 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.64 (exc)
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 4.14.256 (inc) to 4.15 (exc)
linux linux_kernel From 4.19.218 (inc) to 4.20 (exc)
linux linux_kernel From 4.9.291 (inc) to 4.10 (exc)
linux linux_kernel From 5.10.82 (inc) to 5.10.248 (exc)
linux linux_kernel From 5.15.5 (inc) to 5.15.198 (exc)
linux linux_kernel From 5.16.1 (inc) to 6.1.160 (exc)
linux linux_kernel From 5.4.162 (inc) to 5.5 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-667 The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a deadlock issue in the Linux kernel's NFC subsystem. It occurs due to a lock ordering inversion between two locks: device_lock and rfkill_global_mutex. Specifically, one thread (rfkill_fop_write) locks rfkill_global_mutex first and then tries to acquire device_lock, while another thread (nfc_unregister_device) locks device_lock first and then tries to acquire rfkill_global_mutex. This creates a classic ABBA deadlock scenario where each thread waits indefinitely for the other to release a lock. The fix involves moving rfkill_unregister() and rfkill_destroy() calls outside the device_lock critical section to prevent this deadlock.


How can this vulnerability impact me? :

This deadlock vulnerability can cause the affected system to hang or freeze when NFC devices are being unregistered or when rfkill operations are performed concurrently. This can lead to denial of service conditions where NFC functionality becomes unresponsive, potentially impacting applications or services relying on NFC communication.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the deadlock issue between nfc_unregister_device and rfkill_fop_write has been fixed. The fix involves moving rfkill_unregister() and rfkill_destroy() calls outside the device_lock critical section to prevent the deadlock. Until the update is applied, avoid operations that trigger concurrent calls to nfc_unregister_device() and rfkill_fop_write() to reduce the risk of deadlock.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart