linux-cve-announce - CVE-2022-49446: nvdimm: Fix firmware activation deadlock scenarios

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: <2025022658-CVE-2022-49446-f39e@gregkh>
Date: Wed, 26 Feb 2025 03:12:00 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2022-49446: nvdimm: Fix firmware activation deadlock scenarios

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

nvdimm: Fix firmware activation deadlock scenarios

Lockdep reports the following deadlock scenarios for CXL root device
power-management, device_prepare(), operations, and device_shutdown()
operations for 'nd_region' devices:

 Chain exists of:
   &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(system_transition_mutex);
                                lock(&nvdimm_bus->reconfig_mutex);
                                lock(system_transition_mutex);
   lock(&nvdimm_region_key);

 Chain exists of:
   &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&cxl_root_key);
                                lock(acpi_scan_lock);
                                lock(&cxl_root_key);
   lock(&cxl_nvdimm_bridge_key);

These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec()
which walks the entire system device topology taking device_lock() along
the way. The nvdimm_bus_lock() is protecting against unregistration,
multiple simultaneous ops callers, and preventing activate_show() from
racing activate_store(). For the first 2, the lock is redundant.
Unregistration already flushes all ops users, and sysfs already prevents
multiple threads to be active in an ops handler at the same time. For
the last userspace should already be waiting for its last
activate_store() to complete, and does not need activate_show() to flush
the write side, so this lock usage can be deleted in these attributes.

The Linux kernel CVE team has assigned CVE-2022-49446 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.9 with commit 48001ea50d17f3eb06a552e9ecf21f7fc01b25da and fixed in 5.10.121 with commit 641649f31e20df630310f5c22f26c071acc676d4
	Issue introduced in 5.9 with commit 48001ea50d17f3eb06a552e9ecf21f7fc01b25da and fixed in 5.15.46 with commit 2f97ebc58d5fc83ca1528cd553fa725472ab3ca8
	Issue introduced in 5.9 with commit 48001ea50d17f3eb06a552e9ecf21f7fc01b25da and fixed in 5.17.14 with commit ceb924ee16b2c8e48dcac3d9ad6be01c40b5a228
	Issue introduced in 5.9 with commit 48001ea50d17f3eb06a552e9ecf21f7fc01b25da and fixed in 5.18.3 with commit 2fd853fdb40afc052de338693df1372f2ead7be7
	Issue introduced in 5.9 with commit 48001ea50d17f3eb06a552e9ecf21f7fc01b25da and fixed in 5.19 with commit e6829d1bd3c4b58296ee9e412f7ed4d6cb390192

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-2022-49446
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:
	drivers/nvdimm/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/641649f31e20df630310f5c22f26c071acc676d4
	https://git.kernel.org/stable/c/2f97ebc58d5fc83ca1528cd553fa725472ab3ca8
	https://git.kernel.org/stable/c/ceb924ee16b2c8e48dcac3d9ad6be01c40b5a228
	https://git.kernel.org/stable/c/2fd853fdb40afc052de338693df1372f2ead7be7
	https://git.kernel.org/stable/c/e6829d1bd3c4b58296ee9e412f7ed4d6cb390192