On Wed, Jul 22, 2026 at 09:07:04PM -0700, Link Lin wrote: > 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
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
