CVE-2022-49980
BaseFortify
Publication date: 2025-06-18
Last updated on: 2025-11-14
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a use-after-free bug in the Linux kernel's USB gadget subsystem. It occurs because the function usb_udc_uevent() accesses the gadget driver's data without properly locking a mutex (udc_lock) that protects this data. If the gadget driver is unregistered (unbound) at the same time as a uevent is being processed, the driver data may be accessed after it has been freed, leading to a use-after-free condition. This race condition was found by the syzbot fuzzer and fixed by ensuring the mutex is held during these accesses.
How can this vulnerability impact me? :
This vulnerability can lead to a use-after-free condition in the kernel, which may cause system instability, crashes, or potentially allow an attacker to execute arbitrary code with kernel privileges. Since it involves a race condition in USB gadget driver handling, it could be exploited to compromise the security or reliability of a system running the affected Linux kernel versions.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update the Linux kernel to a version where the usb_udc_uevent() function has been fixed to properly acquire the udc_lock mutex around accesses to the driver field, preventing the use-after-free race condition.