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

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 10 Aug 2026 16:55:25 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:

> > The commit message was written with help from the lovely Claude. Not the
> > most readable, admittedly :)
> 
> Yeah I did wonder :)
> 
> I'm totally fine with using an LLM to help with language, especially if English
> is not your primary language, but obviously it can go... wrong :)

yup.  Changelogs from Asian developers have become a lot easier to read
in recent times.  But please always carefully review the resulting
output.

> So will always feedback if the commit message is unclear.
> 
> LLMs seem to have a habit of constructing word salads that end up effectively
> like 'the code in English' which ends up confusing more than helping.

I wonder if it would help to put the initial changelog text through the
LLM, but don't show it any code.

> Key thing is keeping things as short and clear as possible.

I pasted the original changelog into Gemini asking "make this shorter"
and got

Issue

  walk_pmd_range() only resets walk->action after the pmd_none()
  check.  For a walker without ->install_pte, a pmd_none() branch jumps
  to the next entry before resetting walk->action.  If ACTION_AGAIN is
  set and the entry becomes none, the loop can return 0 while leaving
  ACTION_AGAIN active.

  Since commit 3b89863c3fa4, walk_pud_range() reads this leaked
  ACTION_AGAIN status and rewalks the PMD range.  Because callbacks
  like ->pmd_entry() and ->pte_hole() have already processed the range
  once, re-executing them advances walk->private beyond the allocated
  buffer, causing an unprivileged out-of-bounds write (e.g., via
  mincore(2)).

Fix

  Move the walk->action = ACTION_SUBTREE reset to the top of the loop
  body in walk_pmd_range().  Apply the same update to walk_pud_range()
  and walk_p4d_range() to maintain code consistency.

Which is at least shorter ;)


We have a description of the userspace-visible runtime effects of the
bug, which is good, especially with cc:stable fixes.  If there's a bug
report or a backtrace to Link: to then please do that.