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]
Date: Fri, 17 May 2024 15:23:49 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-35809: PCI/PM: Drain runtime-idle callbacks before driver removal

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

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

PCI/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtime_idle() callback and the .remove()
callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
unhandled page fault [1].

The problem is that rtsx_pci_runtime_idle() is not expected to be running
after pm_runtime_get_sync() has been called, but the latter doesn't really
guarantee that.  It only guarantees that the suspend and resume callbacks
will not be running when it returns.

However, if a .runtime_idle() callback is already running when
pm_runtime_get_sync() is called, the latter will notice that the runtime PM
status of the device is RPM_ACTIVE and it will return right away without
waiting for the former to complete.  In fact, it cannot wait for
runtime_idle() to complete because it may be called from that callback (it
arguably does not make much sense to do that, but it is not strictly
prohibited).

Thus in general, whoever is providing a .runtime_idle() callback needs
to protect it from running in parallel with whatever code runs after
pm_runtime_get_sync().  [Note that .runtime_idle() will not start after
pm_runtime_get_sync() has returned, but it may continue running then if it
has started earlier.]

One way to address that race condition is to call pm_runtime_barrier()
after pm_runtime_get_sync() (not before it, because a nonzero value of the
runtime PM usage counter is necessary to prevent runtime PM callbacks from
being invoked) to wait for the .runtime_idle() callback to complete should
it be running at that point.  A suitable place for doing that is in
pci_device_remove() which calls pm_runtime_get_sync() before removing the
driver, so it may as well call pm_runtime_barrier() subsequently, which
will prevent the race in question from occurring, not just in the rtsx_pcr
driver, but in any PCI drivers providing .runtime_idle() callbacks.

The Linux kernel CVE team has assigned CVE-2024-35809 to this issue.


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

	Fixed in 4.19.312 with commit 9a87375bb586
	Fixed in 5.4.274 with commit 47d8aafcfe31
	Fixed in 5.10.215 with commit bbe068b24409
	Fixed in 5.15.154 with commit 7cc94dd36e48
	Fixed in 6.1.84 with commit 900b81caf00c
	Fixed in 6.6.24 with commit d86ad8c3e152
	Fixed in 6.7.12 with commit d534198311c3
	Fixed in 6.8.3 with commit 6347348c6aba
	Fixed in 6.9 with commit 9d5286d4e7f6

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-2024-35809
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/pci/pci-driver.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/9a87375bb586515c0af63d5dcdcd58ec4acf20a6
	https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1
	https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491
	https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674
	https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b
	https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989
	https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5
	https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627bdc6970
	https://git.kernel.org/stable/c/9d5286d4e7f68beab450deddbb6a32edd5ecf4bf

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ