[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2026011338-CVE-2025-71079-9f24@gregkh>
Date: Tue, 13 Jan 2026 16:35:38 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-71079: net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write
From: Greg Kroah-Hartman <gregkh@...nel.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.
The Linux kernel CVE team has assigned CVE-2025-71079 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.16 with commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 and fixed in 6.1.160 with commit ee41f4f3ccf8cd6ba3732e867abbec7e6d8d12e5
Issue introduced in 5.16 with commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 and fixed in 6.6.120 with commit 6b93c8ab6f6cda8818983a4ae3fcf84b023037b4
Issue introduced in 5.16 with commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 and fixed in 6.12.64 with commit 8fc4632fb508432895430cd02b38086bdd649083
Issue introduced in 5.16 with commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 and fixed in 6.18.4 with commit f3a8a7c1aa278f2378b2f3a10500c6674dffdfda
Issue introduced in 5.16 with commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 and fixed in 6.19-rc4 with commit 1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5
Issue introduced in 4.4.293 with commit 5ef16d2d172ee56714cff37cd005b98aba08ef5a
Issue introduced in 4.9.291 with commit ff169909eac9e00bf1aa0af739ba6ddfb1b1d135
Issue introduced in 4.14.256 with commit 47244ac0b65bd74cc70007d8e1bac68bd2baad19
Issue introduced in 4.19.218 with commit c45cea83e13699bdfd47842e04d09dd43af4c371
Issue introduced in 5.4.162 with commit 307d2e6cebfca9d92f86c8e2c8e3dd4a8be46ba6
Issue introduced in 5.10.82 with commit 73a0d12114b4bc1a9def79a623264754b9df698e
Issue introduced in 5.15.5 with commit 8a9c61c3ef187d8891225f9b932390670a43a0d3
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2025-71079
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
net/nfc/core.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/ee41f4f3ccf8cd6ba3732e867abbec7e6d8d12e5
https://git.kernel.org/stable/c/6b93c8ab6f6cda8818983a4ae3fcf84b023037b4
https://git.kernel.org/stable/c/8fc4632fb508432895430cd02b38086bdd649083
https://git.kernel.org/stable/c/f3a8a7c1aa278f2378b2f3a10500c6674dffdfda
https://git.kernel.org/stable/c/1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5
Powered by blists - more mailing lists