CVE-2022-48890

What it actually does

Missing scsi_dma_unmap() call on I/O submission failure in storvsc_queuecommand() leaves swiotlb bounce buffers allocated, leaking memory until confidential VMs (or systems booted with swiotlb=force) exhaust available bounce buffer space and can no longer perform I/O.

Why it matters to the business

Under sustained high storage load, affected systems gradually lose the ability to read or write disk data, leading to application failures, service outages, and potential data unavailability in virtualized environments that rely on confidential computing or forced swiotlb.

How an attack unfolds

An attacker or workload generates continuous storage I/O at a rate sufficient to fill the VMBus channel ring buffer. When storvsc_do_io() fails due to a full ring, the bounce buffers allocated by scsi_dma_map() are never released. Repeated failures accumulate leaks until the system can no longer allocate bounce buffers and all further I/O halts.

How to fix it

Upgrade the Linux kernel to a version containing commit 87c71e88f6a6619ffb1ff88f84dff48ef6d57adb or any stable release after 2021-03-05 that includes the scsi_dma_unmap() fix in the storvsc driver.

How to confirm the fix worked

Confirm the running kernel contains commit 87c71e88f6a6619ffb1ff88f84dff48ef6d57adb or later; verify that storvsc_queuecommand() performs scsi_dma_unmap() on submission error paths; monitor bounce buffer allocation counters under load to ensure no net growth after failed I/Os.

Typical attack path

1. Identify a confidential VM or kernel with swiotlb=force using storvsc storage
2. Generate high-volume storage I/O to saturate the VMBus ring buffer
3. Trigger repeated storvsc_do_io() failures
4. Accumulate unreleased swiotlb bounce buffers until exhaustion
5. Cause system-wide I/O failure and denial of service

How to detect it

Review kernel logs for repeated storvsc I/O submission failures accompanied by growing swiotlb allocation; correlate with increasing bounce buffer usage metrics and eventual I/O timeouts or failures; examine dmesg or /proc/meminfo for swiotlb exhaustion indicators on confidential VMs.

What your security team should do

• Prioritize patching all confidential VMs and any systems using swiotlb=force within the next maintenance window
• Apply the fixed kernel version containing commit 87c71e88f6a6619ffb1ff88f84dff48ef6d57adb
• Monitor VMBus ring buffer utilization and swiotlb allocation metrics for early signs of exhaustion
• Review storage workload patterns to reduce sustained high I/O that could trigger ring-buffer-full conditions