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

[Josh Law]

12 Mar 2026 23:22:48 Pedro Falcato <pfalcato@xxxxxxx>:

> On Thu, Mar 12, 2026 at 01:45:31PM -0700, Andrew Morton wrote:
>> 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.
>
> According to my local copy of lib/maple_tree.c:
>
> mas_pop_node() - Get a previously allocated maple node from the maple state.
>
> Note the "previously" :) kmem_cache_alloc_from_sheaf() can only fail if you
> run out of objects in the sheaf.
>
> So yeah, this "bug" looks bogus.
>
> --
> Pedro

Hi Pedro,

I see the comment regarding 'previously allocated' nodes. However,
mas_pop_node() explicitly calls kmem_cache_alloc_from_sheaf() with
GFP_NOWAIT. If there is any path—even an unexpected one—where the
sheaf is exhausted or the allocator fails, the code immediately
performs a memset on the NULL pointer.

Even if this is a 'should never happen' scenario, returning NULL is
safer than a kernel panic. As Andrew noted, the current structure
allows a fall-through directly into a dereference. My patch ensures
we handle that edge case safely.