CVE-2021-47112

What it actually does

Failure to tear down PV features (Async PF, PV EOI, steal time) on the boot CPU during hibernation restore leaves shared memory mappings intact, allowing the hypervisor to write into memory that the restored kernel may reuse for unrelated data.

Why it matters to the business

Virtualized container hosts on AlmaLinux 8 may experience memory corruption or guest crashes after resume from hibernation, increasing operational risk for workloads that rely on snapshot or suspend/resume workflows and requiring urgent patching across many dependent packages.

How an attack unfolds

An attacker with control of the hypervisor or the ability to trigger hibernation on an affected guest triggers a suspend/resume cycle; because the boot CPU never unregisters its PV feature pages, the hypervisor writes into memory the restored kernel treats as free, leading to corruption that can be leveraged for further attacks.

How to fix it

Upgrade the listed packages to the exact fixed versions: fuse-overlayfs to 0.7.8-1.module_el8.5.0+108+00865455, criu and python3-criu to 3.12-9.module_el8.4.0+2496+12421f43 or 3.12-9.module_el8.3.0+2044+12421f43, python-podman-api to 1.2.0-0.2.gitd0a45fe.module_el8.5.0+2635+e4386a39, slirp4netns to 0.4.2-3.git21fdece.module_el8.5.0+2635+e4386a39, toolbox to 0.0.7-1.module_el8.5.0+108+00865455, udica to 0.2.1-2.module_el8.5.0+108+00865455, cockpit-podman to 11-1.module_el8.5.0+108+00865455, containernetworking-plugins to 0.8.3-4.module_el8.5.0+2635+e4386a39, conmon to 2:2.0.15-1.module_el8.5.0+108+00865455, and container-selinux to 2:2.130.0-1.module_el8.5.0+2635+e4386a39; apply kernel updates that include the referenced commit and reboot.

How to confirm the fix worked

Confirm the installed package versions match or exceed the fixed releases above, verify the kernel changelog contains the x86/kvm teardown change, and test a full hibernation/resume cycle on a non-production AlmaLinux 8 system to ensure PV feature pages are properly unregistered.

Typical attack path

1. Gain hypervisor-level access or ability to force guest hibernation
2. Initiate system suspend on the target AlmaLinux 8 guest
3. Restore the guest from the hibernation image
4. Trigger reuse of the stale PV feature pages to corrupt guest memory
5. Escalate via the resulting memory corruption primitive

How to detect it

Review system and hypervisor logs around hibernation and resume events for unexpected guest memory writes or KVM PV feature teardown messages; correlate with container runtime restarts or crashes on AlmaLinux 8 systems.

What your security team should do

• Prioritize patching all listed container-related packages on every AlmaLinux 8 host within the next maintenance window
• Disable or restrict hibernation on production KVM guests until patches are applied
• Add the fixed package versions to automated update policies and image build pipelines
• Monitor EPSS and KEV status for any change in exploit availability