CVE-2022-48890: scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM
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.
Security readout for executives and security teams
Plain-English summary
A Linux storage driver bug can leak bounce-buffer memory when certain VM storage I/O submissions fail. Under heavy I/O, an affected confidential VM can eventually lose the ability to perform I/O. The issue is mainly availability-focused, not described as data theft or remote code execution in the provided sources.
Executive priority
Treat as a targeted availability risk for affected Linux VM fleets. Prioritize patching where storage downtime would interrupt production services, especially confidential VM workloads with heavy I/O.
Technical view
In storvsc_queuecommand(), scsi_dma_map() can allocate swiotlb bounce buffers. If storvsc_do_io() fails, higher layers may retry, but the original DMA mapping was not unmapped. The fix adds scsi_dma_unmap() on I/O submission error, releasing bounce-buffer memory.
Likely exposure
Exposure is most likely in Linux VMs using the storvsc Hyper-V storage path in confidential VM mode. Non-confidential VMs may also be exposed when booted with swiotlb=force. Exact affected downstream kernel packages require vendor mapping.
Exploitation context
The source bundle does not show KEV listing or active exploitation. The likely trigger is operational: repeated I/O submission failures, commonly a full VMBus channel ring buffer under high I/O load, causing memory leakage until I/O fails.
Researcher notes
The evidence supports a resource leak caused by missing DMA unmap on storvsc_do_io() error paths. CVSS, CWE, and exploitability details are not provided. Avoid assuming remote exploitability; validate exposure through kernel version, configuration, and virtualization context.
Mitigation direction
Upgrade to a vendor kernel containing the referenced stable fixes.
Prioritize confidential VMs using storvsc under high I/O load.
Review vendor advisories for exact package versions and backports.
Reduce sustained I/O pressure where immediate patching is not possible.
Validation and detection
Inventory Linux VMs using Hyper-V storvsc storage.
Identify confidential VMs and systems booted with swiotlb=force.
Map running kernel versions to vendor-fixed packages.
Review I/O failure and memory exhaustion symptoms under high load.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-48890 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.