linux-kernel - Re: mm/vmscan.c:3504 walk_pte_range() error: uninitialized symbol 'dirty'.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250527170349.4eb72b40e4c6e2a6c1c6bce6@linux-foundation.org>
Date: Tue, 27 May 2025 17:03:49 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: oe-kbuild@...ts.linux.dev, Yu Zhao <yuzhao@...gle.com>, lkp@...el.com,
 oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org, Linux Memory
 Management List <linux-mm@...ck.org>
Subject: Re: mm/vmscan.c:3504 walk_pte_range() error: uninitialized symbol
 'dirty'.

On Mon, 26 May 2025 15:32:42 +0300 Dan Carpenter <dan.carpenter@...aro.org> wrote:

> > Seems to be notabug because last==NULL on the first loop and in this
> > case walk_update_folio() will immediately return without touching
> > `dirty'.   But gee, I can't blame smatch from getting fooled by this.
> 
> That's true, but if walk_update_folio() we not inlined then we would
> still consider this a bug.  It's undefined behavior in the C standard
> to pass uninitialized variables to a function call and also the UBSan
> checker will detected it as a read at runtime.
> 
> In production systems the compiler is going to set
> "bool dirty = false;" at the start of the function because everyone
> runs with CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO=y.  Should I send a patch
> which does that explicitly?

Yes please.  And please include some sort of comment to prevent people
from optimizing away the fix ;)