lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ