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

[Josh Law]

12 Mar 2026 20:49:21 Josh Law <hlcj1234567@xxxxxxxxx>:

> 12 Mar 2026 20:45:32 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>:
>
>> On Thu, 12 Mar 2026 18:40:53 +0000 Josh Law <hlcj1234567@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>>> ---
>>> 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.