public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: "Harry Yoo (Oracle)" <harry@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
	 Vlastimil Babka <vbabka@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	 Michal Hocko <mhocko@suse.com>,
	Brendan Jackman <jackmanb@google.com>,
	 Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
	 Harry Yoo <harry@kernel.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	 Alexei Starovoitov <ast@kernel.org>, Hao Li <hao.li@linux.dev>,
	 Christoph Lameter <cl@gentwo.org>,
	David Rientjes <rientjes@google.com>,
	 Roman Gushchin <roman.gushchin@linux.dev>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: [PATCH mm-hotfixes v2 0/2] mm/page_alloc,slab: return NULL early from *_nolock() memory allocation APIs in NMI on UP
Date: Mon, 27 Apr 2026 16:09:51 +0900	[thread overview]
Message-ID: <20260427-nolock-api-fix-v2-0-a6b83a92d9a4@kernel.org> (raw)

Due to my mistake, V1 was sent twice w/o proper cover letter and
Cc: stable. Please ignore V1. Apologies for the noise. 

Changes since V1:
- used b4 to send patch series (w/ a proper cover letter) instead of
  my broken git send-email script (Thanks Vlastimil)
- added Cc: stable to patches 1 and 2

On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that
unconditionally succeeds even when the lock is already held.
As a result, alloc_frozen_pages_nolock() and kmalloc_nolock() called
from an NMI context can successfully re-acquire the lock that the
page/slab allocators are already holding (no deadlock because it's
trylock,  but leads to e.g., allocating the same page/object twice and
causing use-after-free).

It was discovered while testing the new kmalloc/kfree_nolock() test case
in the slub_kunit test module with CONFIG_DEBUG_SPINLOCK=y on a UP
kernel.

Patch 1 fixes alloc_frozen_pages_nolock() and
patch 2 fixes kmalloc_nolock().

Note: As pointed out by Vlastimil Babka [1], in theory a kprobe in a
locked section could trigger the same issue. However, fixing that
involves a non-trivial rework (e.g., inventing a new spinlock type) or
introduces unnecessary overhead for all spinlocks on UP (e.g., let all
spinlocks check locked status on UP).

Given that BPF tracing on UP is rare, and it's even more unlikely to
trace a function called from the memory allocator within the locked
section, this patch series addresses the issue only on NMI contexts
(which is rare as well but now covered by the new test case).

[1] https://lore.kernel.org/linux-mm/af3a7fa9-b368-4ffd-964d-9e4fcba863a8@kernel.org

Cc: stable.vger.kernel.org
---
Harry Yoo (Oracle) (2):
      mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP
      mm/slab: return NULL early from kmalloc_nolock() in NMI on UP

 mm/page_alloc.c | 5 +++++
 mm/slub.c       | 4 ++++
 2 files changed, 9 insertions(+)
---
base-commit: ba24da38a519dfcff8cce3f3f2726d7b159a4d75
change-id: 20260427-nolock-api-fix-bd056911e68e

Best regards,
--  
Cheers,
Harry / Hyeonggon



             reply	other threads:[~2026-04-27  7:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27  7:09 Harry Yoo (Oracle) [this message]
2026-04-27  7:09 ` [PATCH mm-hotfixes v2 1/2] mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP Harry Yoo (Oracle)
2026-04-27  7:09 ` [PATCH mm-hotfixes v2 2/2] mm/slab: return NULL early from kmalloc_nolock() " Harry Yoo (Oracle)
2026-04-27  8:00 ` [PATCH mm-hotfixes v2 0/2] mm/page_alloc,slab: return NULL early from *_nolock() memory allocation APIs " Vlastimil Babka (SUSE)
2026-04-27  8:13   ` Harry Yoo (Oracle)

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=20260427-nolock-api-fix-v2-0-a6b83a92d9a4@kernel.org \
    --to=harry@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=cl@gentwo.org \
    --cc=hannes@cmpxchg.org \
    --cc=hao.li@linux.dev \
    --cc=jackmanb@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=ziy@nvidia.com \
    /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