CVE-2021-47319

What it actually does

Failure to free vblk->vqs before calling init_vqs() during virtblk_restore() leaves previously allocated virtqueues unreclaimed, producing a memory leak on each suspend/resume cycle.

Why it matters to the business

Repeated suspend/resume operations on affected Linux systems gradually exhaust kernel memory, eventually causing performance degradation or crashes that interrupt workloads until the system is rebooted.

How an attack unfolds

An attacker with the ability to trigger or observe multiple suspend/resume cycles can repeatedly invoke the restore path, accumulating unreleased memory until the system becomes unstable or is forced into out-of-memory conditions.

How to fix it

Apply the upstream fix that ensures vblk->vqs is freed before init_vqs() is called in virtblk_restore(); update to a Linux kernel version containing commit 47319 or later backports for the running distribution.

How to confirm the fix worked

Confirm the running kernel contains the patch by inspecting the virtio_blk.c source for the vqs free-before-init sequence in virtblk_restore(); alternatively, compare the kernel version against distribution advisories that list the corrected release.

Typical attack path

1. Obtain local or privileged access sufficient to initiate system suspend/resume
2. Trigger or wait for repeated suspend/resume transitions
3. Monitor kernel memory consumption until exhaustion produces denial of service

How to detect it

Review kernel logs and memory accounting counters for sustained growth in virtio or block-layer allocations across multiple suspend/resume events; correlate with virtblk_restore() call sites if source-level tracing is available.

What your security team should do

• Prioritize kernel updates on systems that perform frequent suspend/resume operations
• Monitor kernel memory usage trends on virtio-blk hosts as a compensating control until patches are applied
• Include the updated kernel in standard image rebuild and deployment pipelines