linux-cve-announce - CVE-2021-47436: usb: musb: dsps: Fix the probe error path

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: <2024052238-CVE-2021-47436-5bb9@gregkh>
Date: Wed, 22 May 2024 08:19:39 +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-47436: usb: musb: dsps: Fix the probe error path

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

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

usb: musb: dsps: Fix the probe error path

Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after
initializing musb") has inverted the calls to
dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without
updating correctly the error path. dsps_create_musb_pdev() allocates and
registers a new platform device which must be unregistered and freed
with platform_device_unregister(), and this is missing upon
dsps_setup_optional_vbus_irq() error.

While on the master branch it seems not to trigger any issue, I observed
a kernel crash because of a NULL pointer dereference with a v5.10.70
stable kernel where the patch mentioned above was backported. With this
kernel version, -EPROBE_DEFER is returned the first time
dsps_setup_optional_vbus_irq() is called which triggers the probe to
error out without unregistering the platform device. Unfortunately, on
the Beagle Bone Black Wireless, the platform device still living in the
system is being used by the USB Ethernet gadget driver, which during the
boot phase triggers the crash.

My limited knowledge of the musb world prevents me to revert this commit
which was sent to silence a robot warning which, as far as I understand,
does not make sense. The goal of this patch was to prevent an IRQ to
fire before the platform device being registered. I think this cannot
ever happen due to the fact that enabling the interrupts is done by the
->enable() callback of the platform musb device, and this platform
device must be already registered in order for the core or any other
user to use this callback.

Hence, I decided to fix the error path, which might prevent future
errors on mainline kernels while also fixing older ones.

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

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

	Issue introduced in 4.14.247 with commit 5269937d1483 and fixed in 4.14.252 with commit 5ed60a430fb5
	Issue introduced in 4.19.207 with commit ffc825049ed2 and fixed in 4.19.213 with commit e923bce31ffe
	Issue introduced in 5.4.148 with commit 9a4a6805294f and fixed in 5.4.155 with commit 9ab5d539bc97
	Issue introduced in 5.10.67 with commit 8de01a896c1b and fixed in 5.10.75 with commit 9d89e2871167
	Issue introduced in 5.14.6 with commit 72bb3eafcfdd and fixed in 5.14.14 with commit ff9249aab398
	Issue introduced in 5.13.19 with commit f5b4df24b420

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-47436
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/usb/musb/musb_dsps.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/5ed60a430fb5f3d93e7fef66264daef466b4d10c
	https://git.kernel.org/stable/c/e923bce31ffefe4f60edfc6b84f62d4a858f3676
	https://git.kernel.org/stable/c/9ab5d539bc975b8dcde86eca1b58d836b657732e
	https://git.kernel.org/stable/c/9d89e287116796bf987cc48f5c8632ef3048f8eb
	https://git.kernel.org/stable/c/ff9249aab39820be11b6975a10d94253b7d426fc
	https://git.kernel.org/stable/c/c2115b2b16421d93d4993f3fe4c520e91d6fe801