Re: [PATCH v2 1/2] mm/pagewalk: fix stale walk->action escaping walk_pmd_range()

[Andrew Morton]

On Wed, 12 Aug 2026 05:17:36 +0900 Hyunwoo Kim <imv4bel@xxxxxxxxx> wrote:

> On Tue, Aug 11, 2026 at 12:37:02PM -0700, Andrew Morton wrote:
> > On Wed, 12 Aug 2026 01:18:57 +0900 Hyunwoo Kim <imv4bel@xxxxxxxxx> wrote:
> > 
> > > If ->pmd_entry() sets walk->action = ACTION_AGAIN, the pmd_none()
> > > check is retried. The PMD entry may be cleared at the point of retry.
> > > 
> > > In this case, if walk->ops->install_pte is not specified, the code
> > > continues to the next PMD entry in the range without resetting
> > > walk->action to ACTION_SUBTREE.
> > > 
> > > This leaves walk->action erroneously set to ACTION_AGAIN, which is
> > > incorrect.
> > > 
> > > This was incorrect but not problematic up until commit 3b89863c3fa4
> > > ("mm/pagewalk: fix race between concurrent split and refault")
> > > which updated walk_pud_range() to check for walk->action ==
> > > ACTION_AGAIN upon walk_pmd_range()'s return, causing the PUD walk
> > > to be retried.
> > > 
> > > In this case this results in duplicate walk callbacks being
> > > invoked, which is erroneous and will break any caller that is not
> > > idempotent with respect to this (and waste time for those which
> > > are).
> > 
> > "break".  Please describe the breakage completely.  It's really the
> > most important information in the whole effort.
> > 
> > IOW, when fixing a bug please describe the userspace-visible runtime
> > effects of that bug.
> > 
> > eg, what were the results of the fuzzer?  
> 
> To be precise, this is an out-of-bounds write.
> 
> > Is there a Link:?  
> 
> This came from a local fuzzer, so there is no Link:

OK, thanks.

> 
> > A stack trace?
> 
> ...
> 
> Should I send a v3 with the changelog fixed? (in 24 hours, I guess?)
> 

That's OK, I pasted it in there.