All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Law <hlcj1234567@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Andrew Ballance <andrewjballance@gmail.com>,
	Josh Law <objecting@objecting.org>,
	maple-tree@lists.infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] lib/maple_tree: fix potential NULL dereference in mas_pop_node()
Date: Thu, 12 Mar 2026 20:49:20 +0000	[thread overview]
Message-ID: <b6327414-237a-4262-bf07-c506908fa263@gmail.com> (raw)
In-Reply-To: <20260312134531.49c1f9171b4b0bc8352e678d@linux-foundation.org>

12 Mar 2026 20:45:32 Andrew Morton <akpm@linux-foundation.org>:

> On Thu, 12 Mar 2026 18:40:53 +0000 Josh Law <hlcj1234567@gmail.com> wrote:
>
>> If kmem_cache_alloc_from_sheaf() returns NULL (possible under
>> GFP_NOWAIT pressure), mas_pop_node() falls through to the out label
>> and dereferences the NULL pointer in memset(ret, 0, sizeof(*ret)).
>
> This is such a glaring bug that I wonder if we're missing something.
>
>> Add a WARN_ON_ONCE NULL check after the sheaf allocation to bail out
>> early, matching the existing pattern for the !mas->sheaf case above.
>>
>> Signed-off-by: Josh Law <objecting@objecting.org>
>> ---
>> lib/maple_tree.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
>> index 739918e859e5..87a2ba6468ca 100644
>> --- a/lib/maple_tree.c
>> +++ b/lib/maple_tree.c
>> @@ -1063,6 +1063,8 @@ static __always_inline struct maple_node *mas_pop_node(struct ma_state *mas)
>>         return NULL;
>>
>>     ret = kmem_cache_alloc_from_sheaf(maple_node_cache, GFP_NOWAIT, mas->sheaf);
>> +   if (WARN_ON_ONCE(!ret))
>> +       return NULL;
>
> If we're going to do this then we may as well restore !__GFP_NOWARN,
> get more relevant information.
>
> But a GFP_NOWAIT allocation attempt can fail relatively easily so
> callers must be equipped to handle it - perhaps no need for any
> warning.

Well, fair enough, but WARN_ON is equivalent to a "oops! Something went wrong! We will continue anyway", NOWARN is quite bad for logging that that went wrong, usually it's BUG_ON that causes said kernel panics and that, which is a bit overkill, that's why I didn't add it, and it warns once, then bails, that's why I'm a bit on the iffy side about adding NOWARN, what's your opinion on this, do you think a NOWARN is better then warn on once?


V/R



Josh law


  reply	other threads:[~2026-03-12 20:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-12 18:40 [PATCH 1/3] lib/maple_tree: fix potential NULL dereference in mas_pop_node() Josh Law
2026-03-12 18:40 ` [PATCH 2/3] lib/maple_tree: fix always-true condition in mas_erase() Josh Law
2026-04-01  3:24   ` Liam R. Howlett
2026-03-12 20:45 ` [PATCH 1/3] lib/maple_tree: fix potential NULL dereference in mas_pop_node() Andrew Morton
2026-03-12 20:49   ` Josh Law [this message]
2026-03-12 20:56     ` Josh Law
2026-03-12 21:14       ` Josh Law
2026-03-12 23:00     ` Alice Ryhl
2026-03-12 23:22   ` Pedro Falcato
2026-03-13  7:17     ` Josh Law
2026-03-13  9:05       ` Pedro Falcato
2026-03-13 16:11         ` Josh Law

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=b6327414-237a-4262-bf07-c506908fa263@gmail.com \
    --to=hlcj1234567@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=aliceryhl@google.com \
    --cc=andrewjballance@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maple-tree@lists.infradead.org \
    --cc=objecting@objecting.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.