LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

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.
Prepared
Confidence
high
Sources
4

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

0CVSS vectors
3Timeline events
1ADP providers
3Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux743b237c3a7b0f5b44aa704aae8a1058877b6322, 743b237c3a7b0f5b44aa704aae8a1058877b6322unaffected
LinuxLinux5.17, 0, 6.1.7, 6.2affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.