linux-cve-announce - CVE-2021-47192: scsi: core: sysfs: Fix hang when device state is set via sysfs

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]

Date: Wed, 10 Apr 2024 20:57:41 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2021-47192: scsi: core: sysfs: Fix hang when device state is set via sysfs

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

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

scsi: core: sysfs: Fix hang when device state is set via sysfs

This fixes a regression added with:

commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after
offlinining device")

The problem is that after iSCSI recovery, iscsid will call into the kernel
to set the dev's state to running, and with that patch we now call
scsi_rescan_device() with the state_mutex held. If the SCSI error handler
thread is just starting to test the device in scsi_send_eh_cmnd() then it's
going to try to grab the state_mutex.

We are then stuck, because when scsi_rescan_device() tries to send its I/O
scsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery()
which will return true (the host state is still in recovery) and I/O will
just be requeued. scsi_send_eh_cmnd() will then never be able to grab the
state_mutex to finish error handling.

To prevent the deadlock move the rescan-related code to after we drop the
state_mutex.

This also adds a check for if we are already in the running state. This
prevents extra scans and helps the iscsid case where if the transport class
has already onlined the device during its recovery process then we don't
need userspace to do it again plus possibly block that daemon.

The Linux kernel CVE team has assigned CVE-2021-47192 to this issue.

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

	Issue introduced in 5.4.143 with commit 69aa1a1a569f and fixed in 5.4.162 with commit edd783162bf2
	Issue introduced in 5.10.61 with commit 711459514e29 and fixed in 5.10.82 with commit a792e0128d23
	Issue introduced in 5.14 with commit f0f82e2476f6 and fixed in 5.15.5 with commit bcc0e3175a97
	Issue introduced in 5.14 with commit f0f82e2476f6 and fixed in 5.16 with commit 4edd8cd4e86d
	Issue introduced in 5.13.13 with commit c6751ce1a2a4

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-2021-47192
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/scsi/scsi_sysfs.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/edd783162bf2385b43de6764f2d4c6e9f4f6be27
	https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73
	https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8
	https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f