Re: [PATCH 1/3] lib/maple_tree: fix potential NULL dereference in mas_pop_node()

Josh Law
2026-03-12T21:15:04Z

12 Mar 2026 20:56:16 Josh Law <hlcj1234567@gmail.com>:

> 12 Mar 2026 20:49:21 Josh Law <hlcj1234567@gmail.com>:
>
>> 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
>
> I checked the callers as you suggested. In lib/maple_tree.c at lines 2352 and 6039, mas_pop_node() is called inside loops where the return value is used immediately (passed to ma_mnode_ptr or bitwise-ORed) without any NULL validation.
> If kmem_cache_alloc_from_sheaf() fails under GFP_NOWAIT pressure, these callers will trigger a kernel panic.

Yeah in my opinion I think this may need to be merged.. if you would like I can add the NOWARN

V/R