linux-cve-announce.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: CVE-2024-26935: scsi: core: Fix unremoved procfs host directory regression
Date: Wed,  1 May 2024 07:21:26 +0200	[thread overview]
Message-ID: <2024050124-CVE-2024-26935-8b4e@gregkh> (raw)

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

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

scsi: core: Fix unremoved procfs host directory regression

Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
directory earlier") fixed a bug related to modules loading/unloading, by
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
to a potential duplicate call to the hostdir_rm() routine, since it's also
called from scsi_host_dev_release(). That triggered a regression report,
which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
directory removal regression"). The fix just dropped the hostdir_rm() call
from dev_release().

But it happens that this proc directory is created on scsi_host_alloc(),
and that function "pairs" with scsi_host_dev_release(), while
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
reason for removing the proc directory on dev_release() was meant to cover
cases in which a SCSI host structure was allocated, but the call to
scsi_add_host() didn't happen. And that pattern happens to exist in some
error paths, for example.

Syzkaller causes that by using USB raw gadget device, error'ing on
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
that the BadDevice label leads to a scsi_host_put() after a SCSI host
allocation, but there's no call to scsi_add_host() in such path. That leads
to messages like this in dmesg (and a leak of the SCSI host proc
structure):

usb-storage 4-1:87.51: USB Mass Storage device detected
proc_dir_entry 'scsi/usb-storage' already registered
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376

The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
but guard that with the state check for SHOST_CREATED; there is even a
comment in scsi_host_dev_release() detailing that: such conditional is
meant for cases where the SCSI host was allocated but there was no calls to
{add,remove}_host(), like the usb-storage case.

This is what we propose here and with that, the error path of usb-storage
does not trigger the warning anymore.

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


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

	Issue introduced in 5.4.238 with commit 88c3d3bb6469 and fixed in 5.4.274 with commit 0053f15d50d5
	Issue introduced in 5.10.176 with commit 68c665bb1850 and fixed in 5.10.215 with commit 5c2386ba80e7
	Issue introduced in 5.15.104 with commit 2a764d55e938 and fixed in 5.15.154 with commit cea234bb214b
	Issue introduced in 6.1.21 with commit 7e0ae8667fcd and fixed in 6.1.84 with commit 3678cf67ff71
	Issue introduced in 6.3 with commit be03df3d4bfe and fixed in 6.6.24 with commit d4c34782b6d7
	Issue introduced in 6.3 with commit be03df3d4bfe and fixed in 6.7.12 with commit e293c773c13b
	Issue introduced in 6.3 with commit be03df3d4bfe and fixed in 6.8.3 with commit f4ff08fab66e
	Issue introduced in 6.3 with commit be03df3d4bfe and fixed in 6.9-rc2 with commit f23a4d6e0757
	Issue introduced in 6.2.8 with commit 73f030d4ef6d

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-26935
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/hosts.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/0053f15d50d50c9312d8ab9c11e2e405812dfcac
	https://git.kernel.org/stable/c/5c2386ba80e779a92ec3bb64ccadbedd88f779b1
	https://git.kernel.org/stable/c/cea234bb214b17d004dfdccce4491e6ff57c96ee
	https://git.kernel.org/stable/c/3678cf67ff7136db1dd3bf63c361650db5d92889
	https://git.kernel.org/stable/c/d4c34782b6d7b1e68d18d9549451b19433bd4c6c
	https://git.kernel.org/stable/c/e293c773c13b830cdc251f155df2254981abc320
	https://git.kernel.org/stable/c/f4ff08fab66eb5c0b97e1a24edac052fb40bf5d7
	https://git.kernel.org/stable/c/f23a4d6e07570826fe95023ca1aa96a011fa9f84

                 reply	other threads:[~2024-05-01  5:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024050124-CVE-2024-26935-8b4e@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).