CVE-2022-50149
BaseFortify
Publication date: 2025-06-18
Last updated on: 2025-11-17
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) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-667 | The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a potential deadlock in the Linux kernel's __driver_attach function. It occurs when asynchronous device probing is allowed, but due to memory allocation failure or work queue limits, the asynchronous work cannot be scheduled and instead is executed synchronously. This synchronous execution attempts to acquire a device lock that is already held, causing an AA (async-async) deadlock. The issue arises because the async_schedule_dev call is made while holding the device lock, leading to a circular wait condition. The fix involves moving the async_schedule_dev call outside the device lock to prevent the deadlock.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to deadlock during device driver attachment, which may result in system hangs or freezes. Such deadlocks can disrupt normal system operation, potentially causing downtime or requiring a reboot to recover. This impacts system stability and reliability, especially in environments where device drivers are frequently loaded or probed asynchronously.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by observing kernel logs for deadlock or hung task messages related to __driver_attach or async scheduling. For example, checking dmesg or /var/log/kern.log for stack traces similar to the provided call trace indicating a deadlock in __driver_attach_async_helper. You can use commands like 'dmesg | grep __driver_attach' or 'journalctl -k | grep __driver_attach' to find relevant messages. Additionally, monitoring for hung tasks or deadlocks using 'cat /proc/sys/kernel/hung_task_timeout_secs' and kernel debug messages can help detect this issue.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves applying the fix that moves async_schedule_dev outside of device_lock to prevent the deadlock. Since this is a kernel-level issue, updating the Linux kernel to a version that includes this fix is the recommended step. As a temporary workaround, you can disable hung task timeout messages by running 'echo 0 > /proc/sys/kernel/hung_task_timeout_secs' to avoid system hangs, but this does not fix the underlying deadlock. Ultimately, upgrading the kernel to a patched version is necessary.