From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DDA14334D7 for ; Mon, 10 Aug 2026 18:16:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786385801; cv=none; b=YbaklVWqRaSxOAAe0fojflOSDtfxGNO3Ap+35x4QPc6h4hBpJfFO46fqAGs+XipZbdnciLk/OX0Rmwk+UzGBTcFNKHntojXUZAtK4BwLAmmGrwm9l0SeNNtVLzQ1j7EPM/sOcFJfTbQAFK5qKuEJFfqbj9SbTHP5Ci6y2QcECaU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786385801; c=relaxed/simple; bh=wVnhLB2oA8K+JHPAZPOAo5DHGbv8bpjDRGwpXtL0NUE=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=XSQYv9XvC0lh4oUmMjbtyPF+L1FUwoALUWmwqLJgujPWe1G5B1K+vi2A+WMvY5fI64wuwTfQ+MfPp62+QaEdCvRvLkWRfggXFlia0Wa5p1MK1SHPdckIYJaIykXXW+HJujWwuQby52QICcXWRsepylPfjT5ou9pH6ay73qyODfs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=aWJd7o70; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="aWJd7o70" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6BFAB1F000E9; Mon, 10 Aug 2026 18:16:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1786385799; bh=l9v3XCGMAYCML1J+iBIiEolvMLJwBNI7ascubHjizwg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=aWJd7o7043rJu1KiN6o4YCzJmTqPhi9QwvUI4mXf1iewvADqQILiNN7cnAqQaytIP qz0UK+mbd55Y82TfU3W7VqJ4qtB6+y7RqNnCGjTG53vN2sOJtjBCUEIKebqhI+X9Uo dWeIievZoi+OyI2ocPZ0btGhlzeWVipXPGcavxkc= Date: Mon, 10 Aug 2026 11:16:38 -0700 From: Andrew Morton To: "Lorenzo Stoakes (ARM)" Cc: Hyunwoo Kim , david@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/pagewalk: fix stale walk->action escaping walk_pmd_range() Message-Id: <20260810111638.a74d094a8a198e84bb6fa5cb@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 10 Aug 2026 16:55:25 +0100 "Lorenzo Stoakes (ARM)" 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.