linux-kernel - Re: [PATCH v2] mm: kmsan: remove runtime checks from kmsan_unpoison

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: <CAG_fn=VBPy9vYTUvdW5Bp9MHF3F2kAhqBKeEg6GHXk0_MG-fiw@mail.gmail.com>
Date: Fri, 26 Jan 2024 17:57:04 +0100
From: Alexander Potapenko <glider@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	kasan-dev@...glegroups.com, Marco Elver <elver@...gle.com>, 
	Dmitry Vyukov <dvyukov@...gle.com>, Ilya Leoshkevich <iii@...ux.ibm.com>, 
	Nicholas Miehlbradt <nicholas@...ux.ibm.com>
Subject: Re: [PATCH v2] mm: kmsan: remove runtime checks from kmsan_unpoison_memory()

On Fri, Jan 26, 2024 at 2:34 AM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Wed, 24 Jan 2024 18:31:34 +0100 Alexander Potapenko <glider@...gle.com> wrote:
>
> > Similarly to what's been done in commit ff444efbbb9be ("kmsan: allow
>
> I make that 85716a80c16d.
>
> > using __msan_instrument_asm_store() inside runtime"), it should be safe
> > to call kmsan_unpoison_memory() from within the runtime, as it does not
> > allocate memory or take locks. Remove the redundant runtime checks.
> >
> > This should fix false positives seen with CONFIG_DEBUG_LIST=y when
> > the non-instrumented lib/stackdepot.c failed to unpoison the memory
> > chunks later checked by the instrumented lib/list_debug.c
> >
> > Also replace the implementation of kmsan_unpoison_entry_regs() with
> > a call to kmsan_unpoison_memory().
> >
>
> "false positives" sound unpleasant.  Should this fix be backported into
> earlier kernels?  And can we identify a suitable Fixes: target?
>

Surprisingly, I haven't seen these false reports before, but the bug
has been there since KMSAN's early downstream days (at the time we
might have needed to have those checks).
So it should probably be:

Fixes: f80be4571b19b9 ("kmsan: add KMSAN runtime core")