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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2024071640-CVE-2022-48790-ca2a@gregkh>
Date: Tue, 16 Jul 2024 13:45:42 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2022-48790: nvme: fix a possible use-after-free in controller reset during load

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

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

nvme: fix a possible use-after-free in controller reset during load

Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl
readiness for AER submission. This may lead to a use-after-free
condition that was observed with nvme-tcp.

The race condition may happen in the following scenario:
1. driver executes its reset_ctrl_work
2. -> nvme_stop_ctrl - flushes ctrl async_event_work
3. ctrl sends AEN which is received by the host, which in turn
   schedules AEN handling
4. teardown admin queue (which releases the queue socket)
5. AEN processed, submits another AER, calling the driver to submit
6. driver attempts to send the cmd
==> use-after-free

In order to fix that, add ctrl state check to validate the ctrl
is actually able to accept the AER submission.

This addresses the above race in controller resets because the driver
during teardown should:
1. change ctrl state to RESETTING
2. flush async_event_work (as well as other async work elements)

So after 1,2, any other AER command will find the
ctrl state to be RESETTING and bail out without submitting the AER.

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


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

	Fixed in 4.19.231 with commit a25e460fbb03
	Fixed in 5.4.181 with commit 70356b756a58
	Fixed in 5.10.102 with commit 0ead57ceb21b
	Fixed in 5.15.25 with commit e043fb5a0336
	Fixed in 5.16.11 with commit 9e956a2596ae
	Fixed in 5.17 with commit 0fa0f99fc84e

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-48790
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/nvme/host/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/a25e460fbb0340488d119fb2e28fe3f829b7417e
	https://git.kernel.org/stable/c/70356b756a58704e5c8818cb09da5854af87e765
	https://git.kernel.org/stable/c/0ead57ceb21bbf15963b4874c2ac67143455382f
	https://git.kernel.org/stable/c/e043fb5a0336ee74614e26f0d9f36f1f5bb6d606
	https://git.kernel.org/stable/c/9e956a2596ae276124ef0d96829c013dd0faf861
	https://git.kernel.org/stable/c/0fa0f99fc84e41057cbdd2efbfe91c6b2f47dd9d

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ