CVE-2023-52762

What it actually does

An implicit size_t to u32 conversion in virtio-blk allows virtio_max_dma_size values exceeding U32_MAX to wrap to zero, causing the driver to use an incorrect (zero) maximum DMA size.

Why it matters to the business

Virtual machines relying on virtio block devices may suffer degraded I/O performance, failed large transfers, or instability when the hypervisor advertises DMA sizes larger than 4 GB.

How an attack unfolds

An attacker with the ability to influence DMA size parameters passed to a vulnerable virtio-blk instance supplies a value larger than 4 GB; the overflow silently sets the limit to zero, resulting in subsequent block I/O operations failing or behaving unexpectedly.

How to fix it

Upgrade the Linux kernel to a version containing commit 21dfa78609ffd8b6bd8143805678ebbacae5141a (or the equivalent back-port) that replaces the u32 cast with a safe U32_MAX cap.

How to confirm the fix worked

Confirm the presence of the fix by inspecting the virtio-blk source for the U32_MAX guard around virtio_max_dma_size; recompile and boot-test a kernel containing the patch to verify no overflow occurs on large DMA sizes.

Typical attack path

1. Gain access to a guest or hypervisor context that can control virtio-blk DMA sizing
2. Issue a request or configuration that causes virtio_max_dma_size to return a value > U32_MAX
3. Observe or trigger the resulting zero-size DMA limit to disrupt block device operations

How to detect it

Review kernel logs for virtio-blk DMA size warnings or I/O errors on systems that should support transfers larger than 4 GB; correlate with hypervisor-reported device sizes.

What your security team should do

• Prioritize kernel updates on all systems exposing virtio-blk devices
• Monitor EPSS and KEV status; although currently low, re-evaluate if exploit maturity changes
• Apply the patch referenced in the fixed commit across affected distributions