[PATCH v3] mm/page_reporting: use system_freezable_wq to fix UAF during suspend

[PATCH v3] mm/page_reporting: use system_freezable_wq to fix UAF during suspend

[Link Lin]

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.

Fixes: 924a663f75e2 ("virtio-balloon: Reporting free page reservations")
Cc: stable@vger.kernel.org
Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Link Lin <linkl@google.com>
---
v3:
  - Dropped Patch 2/2 (virtio_balloon shrinker flag). Freeing pages via
    the shrinker only returns pages to MM; with page reporting work now
    properly serialized on system_freezable_wq, shrinker execution during
    freeze is harmless and requires no additional locking/flags in
    virtio_balloon.
  - Link to v2: https://lore.kernel.org/all/20260717002311.681748-1-linkl@google.com/

v2:
  - Split into a 2-patch series including explicit shrinker fencing.
  - Link to RFC: https://lore.kernel.org/all/20260709224330.946683-1-linkl@google.com/

 mm/page_reporting.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/page_reporting.c b/mm/page_reporting.c
index 7418f2e500..4dc6f4b852 100644
--- a/mm/page_reporting.c
+++ b/mm/page_reporting.c
@@ -80,7 +80,8 @@ __page_reporting_request(struct page_reporting_dev_info *prdev)
 	 * now we are limiting this to running no more than once every
 	 * couple of seconds.
 	 */
-	schedule_delayed_work(&prdev->work, PAGE_REPORTING_DELAY);
+	queue_delayed_work(system_freezable_wq, &prdev->work,
+			   PAGE_REPORTING_DELAY);
 }
 
 /* notify prdev of free page reporting request */
@@ -343,7 +344,8 @@ static void page_reporting_process(struct work_struct *work)
 	 */
 	state = atomic_cmpxchg(&prdev->state, state, PAGE_REPORTING_IDLE);
 	if (state == PAGE_REPORTING_REQUESTED)
-		schedule_delayed_work(&prdev->work, PAGE_REPORTING_DELAY);
+		queue_delayed_work(system_freezable_wq, &prdev->work,
+				   PAGE_REPORTING_DELAY);
 }
 
 static DEFINE_MUTEX(page_reporting_mutex);
-- 
2.55.0

Re: [PATCH v3] mm/page_reporting: use system_freezable_wq to fix UAF during suspend

[Andrew Morton]

On Tue, 21 Jul 2026 00:55:33 +0000 Link Lin <linkl@google.com> wrote:

> 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().
> 
> ...
> 
> Fix this by switching page reporting work to system_freezable_wq.
>
> ...
>

Thanks.

> Fixes: 924a663f75e2 ("virtio-balloon: Reporting free page reservations")

hm, now where did that come from.  I can find no such commit and that's
the second time this very unusual thing has happened in 30 minutes!  I
wonder what's going on.

I'll use

	36e66c554b5c ("mm: introduce Reported pages")

OK?

> Cc: stable@vger.kernel.org

The bug is very old so I won't fast-track this fix into 7.2-rcX.

AI review pointed at a possible pre-existing use-after-free issue,
related to virtio-balloon.  But I think this is a rephrasing of the
issue it flagged against your v2 patch.

	https://sashiko.dev/#/patchset/20260721005603.1710551-1-linkl@google.com

Re: [PATCH v3] mm/page_reporting: use system_freezable_wq to fix UAF during suspend

[Link Lin]

On Tue, Jul 21, 2026 at 5:36 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> hm, now where did that come from. I can find no such commit and that's
> the second time this very unusual thing has happened in 30 minutes! I
> wonder what's going on.
>
> I'll use
> 36e66c554b5c ("mm: introduce Reported pages")
> OK?

Yes, that Fixes tag is perfectly OK. I pulled the previous hash from
an internal downstream tree by mistake. Thank you for catching that
and correcting it!

> The bug is very old so I won't fast-track this fix into 7.2-rcX.

Completely understood and agreed.

> AI review pointed at a possible pre-existing use-after-free issue,
> related to virtio-balloon. But I think this is a rephrasing of the
> issue it flagged against your v2 patch.

I actually looked closely at Sashiko's flag, and to my surprise, it is not a
rephrasing—it caught a completely separate, valid edge case.

My patch fixes the UAF on the PM suspend/teardown path. However, Sashiko noticed
a UAF on the PM *restore* error path. If virtballoon_restore() fails during
init_vqs(), it aborts without unregistering the page reporting worker. When
system_freezable_wq thaws, the reporting worker wakes up and dereferences the
now-dangling vb->reporting_vq pointer.

Since it's a driver-specific lifecycle bug rather than a core MM workqueue
issue, I will write up a separate follow-up patch to address it in
virtio_balloon.c
shortly.

Thank you again for shepherding this fix into -mm!

Best,
Link

Re: [PATCH v3] mm/page_reporting: use system_freezable_wq to fix UAF during suspend

[Michael S. Tsirkin]

On Wed, Jul 22, 2026 at 09:07:04PM -0700, Link Lin wrote:
> On Tue, Jul 21, 2026 at 5:36 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > hm, now where did that come from. I can find no such commit and that's
> > the second time this very unusual thing has happened in 30 minutes! I
> > wonder what's going on.
> >
> > I'll use
> > 36e66c554b5c ("mm: introduce Reported pages")
> > OK?
> 
> Yes, that Fixes tag is perfectly OK. I pulled the previous hash from
> an internal downstream tree by mistake. Thank you for catching that
> and correcting it!
> 
> > The bug is very old so I won't fast-track this fix into 7.2-rcX.
> 
> Completely understood and agreed.
> 
> > AI review pointed at a possible pre-existing use-after-free issue,
> > related to virtio-balloon. But I think this is a rephrasing of the
> > issue it flagged against your v2 patch.
> 
> I actually looked closely at Sashiko's flag, and to my surprise, it is not a
> rephrasing—it caught a completely separate, valid edge case.
> 
> My patch fixes the UAF on the PM suspend/teardown path. However, Sashiko noticed
> a UAF on the PM *restore* error path. If virtballoon_restore() fails during
> init_vqs(), it aborts without unregistering the page reporting worker. When
> system_freezable_wq thaws, the reporting worker wakes up and dereferences the
> now-dangling vb->reporting_vq pointer.
> 
> Since it's a driver-specific lifecycle bug rather than a core MM workqueue
> issue, I will write up a separate follow-up patch to address it in
> virtio_balloon.c
> shortly.
> 
> Thank you again for shepherding this fix into -mm!
> 
> Best,
> Link


I suspect rest of work items we have, e.g. update_balloon_stats_work/update_balloon_size_work
all have issues around freeze/restore and error handling.

-- 
MST