CVE-2022-48760

CVE Details

Release Date:

2024-06-20

Description

In the Linux kernel, the following vulnerability has been resolved:\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\nThe syzbot fuzzer has identified a bug in which processes hang waiting\nfor usb_kill_urb() to return. It turns out the issue is not unlinking\nthe URB; that works just fine. Rather, the problem arises when the\nwakeup notification that the URB has completed is not received.\nThe reason is memory-access ordering on SMP systems. In outline form,\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\ndifferent CPUs perform the following actions:\nCPU 0CPU 1\n-------------------------------------------------------------\nusb_kill_urb():__usb_hcd_giveback_urb():\n... ...\natomic_inc(&urb->reject); atomic_dec(&urb->use_count);\n... ...\nwait_event(usb_kill_urb_queue,\natomic_read(&urb->use_count) == 0);\nif (atomic_read(&urb->reject))\nwake_up(&usb_kill_urb_queue);\nConfining your attention to urb->reject and urb->use_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\nwrite urb->reject, then read urb->use_count;\nwhereas the overall pattern of accesses on CPU 1 is:\nwrite urb->use_count, then read urb->reject.\nThis pattern is referred to in memory-model circles as SB (for 'Store\nBuffering'), and it is well known that without suitable enforcement of\nthe desired order of accesses -- in the form of memory barriers -- it\nis entirely possible for one or both CPUs to execute their reads ahead\nof their writes. The end result will be that sometimes CPU 0 sees the\nold un-decremented value of urb->use_count while CPU 1 sees the old\nun-incremented value of urb->reject. Consequently CPU 0 ends up on\nthe wait queue and never gets woken up, leading to the observed hang\nin usb_kill_urb().\nThe same pattern of accesses occurs in usb_poison_urb() and the\nfailure pathway of usb_hcd_submit_urb().\nThe problem is fixed by adding suitable memory barriers. To provide\nproper memory-access ordering in the SB pattern, a full barrier is\nrequired on both CPUs. The atomic_inc() and atomic_dec() accesses\nthemselves don't provide any memory ordering, but since they are\npresent, we can use the optimized smp_mb__after_atomic() memory\nbarrier in the various routines to obtain the desired effect.\nThis patch adds the necessary memory barriers.

See more information about CVE-2022-48760 from MITRE CVE dictionary and NIST NVD

CVSS Scoring

NOTE: The following CVSS v3.1 metrics and score provided are preliminary and subject to review.

Base Score:	4.1	CVSS Vector:	CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
Attack Vector:	Local network	Attack Complexity:	High
Privileges Required:	High	User Interaction:	None
Scope:	Unchanged	Confidentiality Impact:	None
Integrity Impact:	None	Availability Impact:	High

Errata information

Platform	Errata	Release Date
Oracle Linux version 6 (kernel-uek)	ELSA-2024-12806	2024-11-01
Oracle Linux version 7 (kernel-uek)	ELSA-2024-12806	2024-11-01
Oracle Linux version 8 (kernel)	ELSA-2024-7000	2024-09-24
Oracle VM version 3 (kernel-uek)	OVMSA-2024-0015	2024-11-05