CVE-2022-48890 in Linux
Summary
by MITRE • 08/21/2024
In the Linux kernel, the following vulnerability has been resolved:
scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM
storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can't do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force.
Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/17/2026
The vulnerability described in CVE-2022-48890 represents a critical memory leak issue within the Linux kernel's SCSI subsystem, specifically affecting virtualized environments running in confidential computing scenarios. This flaw manifests in the storvsc driver, which handles SCSI operations for Hyper-V virtual machines. The issue is particularly severe in confidential virtual machines where Intel's Software Guard Extensions (SGX) or similar technologies are employed to protect data in use, creating additional complexity in memory management operations. The vulnerability stems from improper handling of bounce buffer allocation and deallocation during SCSI I/O operations, leading to progressive memory consumption that eventually renders the virtual machine incapable of performing any I/O operations.
The technical root cause of this vulnerability lies in the improper synchronization between memory allocation and deallocation within the storvsc_queuecommand function. When the driver processes SCSI commands, it utilizes scsi_dma_map() to map scatter/gather lists for I/O operations. In confidential virtual machine environments, this mapping process triggers allocation of swiotlb (software I/O translation table bounce) buffers to handle DMA operations that cannot directly access guest physical memory. The problem occurs when I/O submission fails within the storvsc_do_io() function, typically due to full VMBus channel ring buffers under high I/O load conditions. The driver correctly retries these failed operations through higher-level code but fails to execute the corresponding scsi_dma_unmap() call to release the allocated bounce buffer memory, creating a memory leak that accumulates over time.
The operational impact of this vulnerability is significant, particularly in high-performance computing environments and cloud infrastructure where confidential VMs handle substantial I/O workloads. Under normal operating conditions, the leak may not be immediately apparent, but as I/O operations continue to fail and retry, the accumulated memory leak progressively consumes available system resources. This degradation can eventually lead to complete I/O paralysis where the virtual machine cannot process any further storage operations, effectively rendering it unusable for its intended purpose. The vulnerability affects not only confidential VMs but also non-confidential VMs when the kernel boot parameter swiotlb=force is enabled, making it a widespread concern across various virtualization deployments. The issue is classified under CWE-401: Improper Release of Memory and aligns with ATT&CK technique T1490: Inhibit System Recovery, as it can lead to complete system unavailability through resource exhaustion.
The mitigation strategy involves implementing proper error handling in the storvsc driver to ensure that scsi_dma_unmap() is called whenever I/O submission fails, regardless of whether the operation is retried or ultimately succeeds. This fix addresses the fundamental issue of resource leak by ensuring that bounce buffer memory allocated through swiotlb is properly freed when I/O operations encounter failures. The solution requires modifying the error handling path in storvsc_do_io() to include explicit cleanup of DMA mappings before retrying failed operations. This approach aligns with industry best practices for memory management in virtualized environments and follows the principle of resource leak prevention as outlined in secure coding standards. The fix ensures that even under high I/O load conditions where VMBus ring buffers frequently become full, the system maintains proper memory hygiene and prevents the progressive degradation that leads to complete I/O failure.