CVE-2025-71079

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.