CVE-2026-74481

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_reporting: use system_freezable_wq to fix UAF during suspend<br /> <br /> During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like<br /> virtio_balloon reset their underlying virtio devices and delete their<br /> virtqueues via vdev-&gt;config-&gt;del_vqs().<br /> <br /> However, page reporting work (page_reporting_process) was scheduled on the<br /> global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM<br /> freezer skips it, leaving page_reporting_process active during suspend.<br /> <br /> If pages are freed into the buddy allocator while suspending (for example,<br /> when core MM invokes the balloon shrinker during S4 hibernation image<br /> saving), page reporting triggers virtballoon_free_page_report() on deleted<br /> virtqueues, resulting in a Use-After-Free / General Protection Fault:<br /> <br /> [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI<br /> [ 196.825967] Workqueue: events page_reporting_process<br /> [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring]<br /> [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon]<br /> [ 196.946943] page_reporting_process+0x370/0x4f0<br /> <br /> Fix this by switching page reporting work to system_freezable_wq. This<br /> ensures that the PM freezer pauses page_reporting_process before device<br /> drivers destroy their reporting virtqueues. Because the reporting worker<br /> is frozen, memory reclamation/freeing (e.g. via shrinker execution) can<br /> safely return pages to MM during freeze without triggering unfrozen<br /> reporting work on deleted virtqueues.<br /> <br /> This aligns with the driver&amp;#39;s existing design. The comment in<br /> virtballoon_freeze() states:<br /> /*<br /> * The workqueue is already frozen by the PM core before this<br /> * function is called.<br /> */<br /> <br /> Testing:<br /> I have verified these fixes using Google’s virtualization infrastructure<br /> by running continuous suspend/resume iterations (40+ cycles) while<br /> churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60%<br /> --timeout 1`) to constantly create free pages for the buddy allocator. We<br /> also set the `page_reporting_order` parameter to 0 to make the page<br /> reporting worker highly sensitive, forcing it to pick up any 4K free<br /> pages. This confirmed that the UAF crashes are no longer reproducible.