linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Alexander Potapenko <glider@google.com>
Cc: Marco Elver <elver@google.com>,
	kasan-dev@googlegroups.com, Dmitry Vyukov <dvyukov@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org, stable@vger.kernel.org,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH] kmsan: Fix out-of-bounds access to shadow memory
Date: Thu, 11 Sep 2025 12:29:53 -0700	[thread overview]
Message-ID: <20250911192953.GG1376@sol> (raw)
In-Reply-To: <20250911190302.GF1376@sol>

On Thu, Sep 11, 2025 at 12:03:02PM -0700, Eric Biggers wrote:
> On Thu, Sep 11, 2025 at 10:51:45AM -0700, Eric Biggers wrote:
> > On Thu, Sep 11, 2025 at 11:09:17AM +0200, Alexander Potapenko wrote:
> > > On Wed, Sep 10, 2025 at 9:49 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > > >
> > > > On Fri, Aug 29, 2025 at 09:45:00AM -0700, Eric Biggers wrote:
> > > > > Running sha224_kunit on a KMSAN-enabled kernel results in a crash in
> > > > > kmsan_internal_set_shadow_origin():
> > > > >
> > > > >     BUG: unable to handle page fault for address: ffffbc3840291000
> > > > >     #PF: supervisor read access in kernel mode
> > > > >     #PF: error_code(0x0000) - not-present page
> > > > >     PGD 1810067 P4D 1810067 PUD 192d067 PMD 3c17067 PTE 0
> > > > >     Oops: 0000 [#1] SMP NOPTI
> > > > >     CPU: 0 UID: 0 PID: 81 Comm: kunit_try_catch Tainted: G                 N  6.17.0-rc3 #10 PREEMPT(voluntary)
> > > > >     Tainted: [N]=TEST
> > > > >     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
> > > > >     RIP: 0010:kmsan_internal_set_shadow_origin+0x91/0x100
> > > > >     [...]
> > > > >     Call Trace:
> > > > >     <TASK>
> > > > >     __msan_memset+0xee/0x1a0
> > > > >     sha224_final+0x9e/0x350
> > > > >     test_hash_buffer_overruns+0x46f/0x5f0
> > > > >     ? kmsan_get_shadow_origin_ptr+0x46/0xa0
> > > > >     ? __pfx_test_hash_buffer_overruns+0x10/0x10
> > > > >     kunit_try_run_case+0x198/0xa00
> > > >
> > > > Any thoughts on this patch from the KMSAN folks?  I'd love to add
> > > > CONFIG_KMSAN=y to my crypto subsystem testing, but unfortunately the
> > > > kernel crashes due to this bug :-(
> > > >
> > > > - Eric
> > > 
> > > Sorry, I was out in August and missed this email when digging through my inbox.
> > > 
> > > Curiously, I couldn't find any relevant crashes on the KMSAN syzbot
> > > instance, but the issue is legit.
> > > Thank you so much for fixing this!
> > > 
> > > Any chance you can add a test case for it to mm/kmsan/kmsan_test.c?
> > 
> > Unfortunately most of the KMSAN test cases already fail on upstream,
> > which makes it difficult to develop new ones:
> 
> The KMSAN test failures bisect to the following commit:
> 
>     commit f90b474a35744b5d43009e4fab232e74a3024cae
>     Author: Vlastimil Babka <vbabka@suse.cz>
>     Date:   Mon Mar 10 13:40:17 2025 +0100
> 
>         mm: Fix the flipped condition in gfpflags_allow_spinning()
> 
> I'm not sure why.  Apparently something related to lib/stackdepot.c.
> 
> Reverting that commit on top of upstream fixes the KMSAN tests.
> 

Rolling back all the BPF (?) related changes that were made to
lib/stackdepot.c in v6.15 fixes this too.  Looks like there was a
regression where stack traces stopped being saved in some cases.

diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index de0b0025af2b9..99e374d35b61d 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -638,12 +638,11 @@ depot_stack_handle_t stack_depot_save_flags(unsigned long *entries,
 	struct list_head *bucket;
 	struct stack_record *found = NULL;
 	depot_stack_handle_t handle = 0;
 	struct page *page = NULL;
 	void *prealloc = NULL;
-	bool allow_spin = gfpflags_allow_spinning(alloc_flags);
-	bool can_alloc = (depot_flags & STACK_DEPOT_FLAG_CAN_ALLOC) && allow_spin;
+	bool can_alloc = depot_flags & STACK_DEPOT_FLAG_CAN_ALLOC;
 	unsigned long flags;
 	u32 hash;
 
 	if (WARN_ON(depot_flags & ~STACK_DEPOT_FLAGS_MASK))
 		return 0;
@@ -678,11 +677,11 @@ depot_stack_handle_t stack_depot_save_flags(unsigned long *entries,
 				   DEPOT_POOL_ORDER);
 		if (page)
 			prealloc = page_address(page);
 	}
 
-	if (in_nmi() || !allow_spin) {
+	if (in_nmi()) {
 		/* We can never allocate in NMI context. */
 		WARN_ON_ONCE(can_alloc);
 		/* Best effort; bail if we fail to take the lock. */
 		if (!raw_spin_trylock_irqsave(&pool_lock, flags))
 			goto exit;
@@ -719,14 +718,11 @@ depot_stack_handle_t stack_depot_save_flags(unsigned long *entries,
 	printk_deferred_exit();
 	raw_spin_unlock_irqrestore(&pool_lock, flags);
 exit:
 	if (prealloc) {
 		/* Stack depot didn't use this memory, free it. */
-		if (!allow_spin)
-			free_pages_nolock(virt_to_page(prealloc), DEPOT_POOL_ORDER);
-		else
-			free_pages((unsigned long)prealloc, DEPOT_POOL_ORDER);
+		free_pages((unsigned long)prealloc, DEPOT_POOL_ORDER);
 	}
 	if (found)
 		handle = found->handle.handle;
 	return handle;
 }


  reply	other threads:[~2025-09-11 19:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29 16:45 [PATCH] kmsan: Fix out-of-bounds access to shadow memory Eric Biggers
2025-09-10 19:49 ` Eric Biggers
2025-09-11  9:09   ` Alexander Potapenko
2025-09-11 17:51     ` Eric Biggers
2025-09-11 19:03       ` Eric Biggers
2025-09-11 19:29         ` Eric Biggers [this message]
2025-09-17  8:31           ` Alexander Potapenko
2025-09-17 15:48             ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250911192953.GG1376@sol \
    --to=ebiggers@kernel.org \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).