CVE-2022-50064
BaseFortify
Publication date: 2025-06-18
Last updated on: 2025-11-13
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 virtio-blk driver. Specifically, the hctx->user_data pointer is set to a virtqueue (vq) during initialization, but this vq is freed during system suspend and reallocated during resume. After resume, hctx->user_data points to freed memory, causing a use-after-free condition that can lead to a kernel crash.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to crash due to use-after-free memory access in the virtio-blk driver during suspend/resume cycles. Such crashes can lead to system instability, potential data loss, and denial of service.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
You can detect this vulnerability by monitoring your system logs for kernel crash messages related to virtio-blk use-after-free errors. Look for kernel panic or crash traces similar to the provided call trace in the description, which includes functions like virtqueue_add_split, virtqueue_add_sgs, and virtblk_add_req. Checking dmesg or /var/log/kern.log for such traces after suspend/resume cycles can help identify the issue. Specific commands to check logs include: 'dmesg | grep -i virtio' or 'journalctl -k | grep -i virtio'.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating the Linux kernel to a version that includes the patch fixing this use-after-free vulnerability in virtio-blk. The patch removes the problematic virtblk_init_hctx() and correctly manages vq on suspend/resume. Until the update is applied, avoid suspending and resuming the system to prevent triggering the use-after-free condition.