linux-kernel - Re: [PATCH] mm/kmsan: Fix kmsan kmalloc hook when no stack depots are allocated yet

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251022030213.GA35717@sol>
Date: Tue, 21 Oct 2025 20:02:13 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Aleksei Nikiforov <aleksei.nikiforov@...ux.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Alexander Potapenko <glider@...gle.com>,
	Marco Elver <elver@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>,
	kasan-dev@...glegroups.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Ilya Leoshkevich <iii@...ux.ibm.com>,
	Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH] mm/kmsan: Fix kmsan kmalloc hook when no stack depots
 are allocated yet

On Fri, Oct 10, 2025 at 10:07:04AM +0200, Aleksei Nikiforov wrote:
> On 10/9/25 05:31, Andrew Morton wrote:
> > On Tue, 30 Sep 2025 13:56:01 +0200 Aleksei Nikiforov <aleksei.nikiforov@...ux.ibm.com> wrote:
> > 
> > > If no stack depot is allocated yet,
> > > due to masking out __GFP_RECLAIM flags
> > > kmsan called from kmalloc cannot allocate stack depot.
> > > kmsan fails to record origin and report issues.
> > > 
> > > Reusing flags from kmalloc without modifying them should be safe for kmsan.
> > > For example, such chain of calls is possible:
> > > test_uninit_kmalloc -> kmalloc -> __kmalloc_cache_noprof ->
> > > slab_alloc_node -> slab_post_alloc_hook ->
> > > kmsan_slab_alloc -> kmsan_internal_poison_memory.
> > > 
> > > Only when it is called in a context without flags present
> > > should __GFP_RECLAIM flags be masked.
> > > 
> > > With this change all kmsan tests start working reliably.
> > 
> > I'm not seeing reports of "hey, kmsan is broken", so I assume this
> > failure only occurs under special circumstances?
> 
> Hi,
> 
> kmsan might report less issues than it detects due to not allocating stack
> depots and not reporting issues without stack depots. Lack of reports may go
> unnoticed, that's why you don't get reports of kmsan being broken.

Yes, KMSAN seems to be at least partially broken currently.  Besides the
fact that the kmsan KUnit test is currently failing (which I reported at
https://lore.kernel.org/r/20250911175145.GA1376@sol), I've confirmed
that the poly1305 KUnit test causes a KMSAN warning with Aleksei's patch
applied but does not cause a warning without it.  The warning did get
reached via syzbot somehow
(https://lore.kernel.org/r/751b3d80293a6f599bb07770afcef24f623c7da0.1761026343.git.xiaopei01@kylinos.cn/),
so KMSAN must still work in some cases.  But it didn't work for me.

(That particular warning in the architecture-optimized Poly1305 code is
actually a false positive due to memory being initialized by assembly
code.  But that's besides the point.  The point is that I should have
seen the warning earlier, but I didn't.  And Aleksei's patch seems to
fix KMSAN to work reliably.  It also fixes the kmsan KUnit test.)

I don't really know this code, but I can at least give:

Tested-by: Eric Biggers <ebiggers@...nel.org>

If you want to add a Fixes commit I think it is either 97769a53f117e2 or
8c57b687e8331.  Earlier I had confirmed that reverting those commits
fixed the kmsan test too
(https://lore.kernel.org/r/20250911192953.GG1376@sol).

- Eric