Subject: CVE-2022-48760: USB: core: Fix hang in usb_kill_urb by adding memory barriers

From: Greg Kroah-Hartman <[email-masked]>

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

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

USB: core: Fix hang in usb_kill_urb by adding memory barriers

The syzbot fuzzer has identified a bug in which processes hang waiting
for usb_kill_urb() to return.  It turns out the issue is not unlinking
the URB; that works just fine.  Rather, the problem arises when the
wakeup notification that the URB has completed is not received.

The reason is memory-access ordering on SMP systems.  In outline form,
usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
different CPUs perform the following actions:

CPU 0					CPU 1
----------------------------		---------------------------------
usb_kill_urb():				__usb_hcd_giveback_urb():
  ...					  ...
  atomic_inc(&urb->reject);		  atomic_dec(&urb->use_count);
  ...					  ...
  wait_event(usb_kill_urb_queue,
	atomic_read(&urb->use_count) == 0);
					  if (atomic_read(&urb->reject))
						wake_up(&usb_kill_urb_queue);

Confining your attention to urb->reject and urb->use_count, you can
see that the overall pattern of accesses on CPU 0 is:

	write urb->reject, then read urb->use_count;

whereas the overall pattern of accesses on CPU 1 is:

	write urb->use_count, then read urb->reject.

This pattern is referred to in memory-model circles as SB (for "Store
Buffering"), and it is well known that without suitable enforcement of
the desired order of accesses -- in the form of memory barriers -- it
is entirely possible for one or both CPUs to execute their reads ahead
of their writes.  The end result will be that sometimes CPU 0 sees the
old un-decremented value of urb->use_count while CPU 1 sees the old
un-incremented value of urb->reject.  Consequently CPU 0 ends up on
the wait queue and never gets woken up, leading to the observed hang
in usb_kill_urb().

The same pattern of accesses occurs in usb_poison_urb() and the
failure pathway of usb_hcd_submit_urb().

The problem is fixed by adding suitable memory barriers.  To provide
proper memory-access ordering in the SB pattern, a full barrier is
required on both CPUs.  The atomic_inc() and atomic_dec() accesses
themselves don't provide any memory ordering, but since they are
present, we can use the optimized smp_mb__after_atomic() memory
barrier in the various routines to obtain the desired effect.

This patch adds the necessary memory barriers.

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

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

	Fixed in 4.4.302 with commit 5f138ef224df
	Fixed in 4.9.300 with commit b50f5ca60475
	Fixed in 4.14.265 with commit 546ba238535d
	Fixed in 4.19.228 with commit 5904dfd3ddaf
	Fixed in 5.4.176 with commit 9c61fce322ac
	Fixed in 5.10.96 with commit e3b131e30e61
	Fixed in 5.15.19 with commit 9340226388c6
	Fixed in 5.16.5 with commit c9a18f7c5b07
	Fixed in 5.17 with commit 26fbe9772b8c

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-48760
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/core/hcd.c
	drivers/usb/core/urb.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/5f138ef224dffd15d5e5c5b095859719e0038427
	https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0
	https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3
	https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
	https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6
	https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193
	https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26
	https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0
	https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf