CVE-2026-74481 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/page_reporting: use system_freezable_wq to fix UAF during suspend
During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs().
However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend.
If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault:
[ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI
[ 196.825967] Workqueue: events page_reporting_process
[ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring]
[ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon]
[ 196.946943] page_reporting_process+0x370/0x4f0
Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues.
This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */
Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in question involves a use-after-free condition within the Linux kernel's memory management subsystem during power management suspend operations. This issue specifically affects systems utilizing virtio balloon drivers and page reporting functionality during S3 suspend or S4 hibernation processes. The root cause lies in the improper scheduling of page reporting work items on the global system workqueue, which lacks the necessary freezer awareness required for safe power management transitions.
During power management freeze operations, device drivers such as virtio_balloon perform critical cleanup tasks including resetting underlying virtio devices and deleting their virtqueues through the vdev->config->del_vqs() interface. However, the page reporting work item page_reporting_process was scheduled on system_wq without the WQ_FREEZABLE flag, causing the PM freezer to ignore this workqueue during suspend operations. This misconfiguration leaves the page reporting process active while device drivers are tearing down their virtqueue structures, creating a dangerous window where memory reclamation operations can trigger use-after-free conditions.
The technical flaw manifests when pages are freed into the buddy allocator during suspend operations, particularly during S4 hibernation image saving when core memory management invokes balloon shrinkers. The page reporting mechanism attempts to call virtballoon_free_page_report() on deleted virtqueues, resulting in general protection faults and system crashes. This scenario represents a classic use-after-free vulnerability classified under CWE-416, where freed memory is accessed after deallocation. The crash trace shows the fault occurring in virtqueue_add_split within the virtio_ring module, demonstrating how the reporting process attempts to access deleted virtqueue structures.
The operational impact of this vulnerability extends beyond simple system instability, as it can lead to complete system crashes during critical power management operations. The vulnerability is particularly concerning in virtualized environments where suspend/resume cycles are frequent and memory pressure is constant. The issue affects systems running Linux kernels where the virtio_balloon driver is active, making it relevant for cloud infrastructure, virtual machines, and containerized environments that rely on these drivers for memory management.
The proposed fix involves switching the page reporting work from system_wq to system_freezable_wq, which properly integrates with the kernel's power management subsystem. This change ensures that the PM freezer can safely pause page_reporting_process before device drivers destroy their reporting virtqueues. The solution aligns with existing driver design patterns as evidenced by comments in virtballoon_freeze() that explicitly state the workqueue is already frozen by the PM core. This approach follows established security practices for handling concurrent access during system transitions and addresses the underlying architectural mismatch between power management requirements and workqueue scheduling.
The fix implementation demonstrates proper adherence to kernel security principles, ensuring that memory reclamation operations can safely return pages to the memory manager during freeze without triggering unfrozen reporting work on deleted structures. Testing validation using Google's virtualization infrastructure confirmed the effectiveness of this approach through extensive suspend/resume cycles with memory stress testing. The solution maintains system stability while preserving all existing functionality, making it a robust and minimal change that addresses the core architectural issue without introducing new risks or performance impacts.
This vulnerability resolution follows ATT&CK framework concept T1490 for 'Inhibit System Recovery' by addressing a critical flaw in power management recovery mechanisms. The fix ensures proper workqueue handling during system transitions, aligning with security best practices for maintaining system integrity during sensitive operations. The approach demonstrates effective vulnerability remediation through architectural correction rather than workarounds, providing long-term stability for systems relying on virtio balloon drivers and page reporting functionality during power management operations.