Re: [PATCH v2] alloc: fix dangling pointer in alloc_state cleanup

From: Torsten Bögershausen <tboegi@web.de>
Date: Aug 28, 2025, 19:29 UTC
Message-ID: <20250828192949.GA18641@tb-raspi4>
In-Reply-To: <pull.2040.v2.git.git.1756337312918.gitgitgadget@gmail.com>

On Wed, Aug 27, 2025 at 11:28:32PM +0000, ノウラ | Flare via GitGitGadget wrote:

Show 9 quoted lines

> From: =?UTF-8?q?=E3=83=8E=E3=82=A6=E3=83=A9=20=7C=20Flare?=
>  <nouraellm@gmail.com>
> 
> clear_alloc_state() freed all slabs and nulled the slabs pointer but
> left slab_alloc, nr, and p unchanged. If the alloc_state is reused,
> ALLOC_GROW() can wrongly assume that the slab array is already
> allocated because slab_alloc still holds a stale nonzero capacity.
> In that case s->slabs remains NULL and the next dereference writes
> through a NULL pointer, causing undefined behavior.

This is good.

> 
> To fix this, this patch:

Style nit, we tend to use the "imperative form" here in Git, like this:

- Rename allocate_alloc_state() → alloc_state_alloc().
- Replace ...
- Update ...

Show 12 quoted lines

> 
> - Renames allocate_alloc_state() → alloc_state_alloc().
> - Replaces the “just clear” API with
>   alloc_state_free_and_null(struct alloc_state **s_),
>   which frees all slabs and the alloc_state itself,
>   and then nulls the caller’s pointer.
> - Updates call sites to use the new helpers and drops
>   redundant FREE_AND_NULL() calls.
> 
> This makes the alloc_state lifecycle API harder to misuse,
> eliminates stale-capacity state,
> and aligns naming with project conventions.