On Tue, Jul 21, 2026 at 5:36 PM Andrew Morton <[email protected]> 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
