Re: [PATCH net-next 06/15] batman-adv: ensure u16 aligned mac address arrays on stack

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On Tuesday, 1 September 2026 15:59:59 CEST sashiko-bot@kernel.org wrote:
[...]
> If memory allocation fails for bat_priv->bla.backbone_hash, the previously
> allocated claim_hash is destroyed but the pointer is left dangling:
> 
> net/batman-adv/bridge_loop_avoidance.c:batadv_bla_init() {
>         ...
>         bat_priv->bla.backbone_hash = batadv_hash_new(32);
>         if (!bat_priv->bla.backbone_hash) {
>                 batadv_hash_destroy(bat_priv->bla.claim_hash);
>                 return -ENOMEM;
>         }
>         ...
> }
> 
> This failure propagates up to batadv_mesh_init() and register_netdevice(),
> which rolls back by calling the device's priv_destructor 
> (batadv_meshif_free()).
> 
> This destructor calls batadv_mesh_free() which unconditionally calls
> batadv_bla_free(). Could batadv_bla_free() then use the dangling non-NULL
> claim_hash pointer:
> 
> net/batman-adv/bridge_loop_avoidance.c:batadv_bla_free() {
>         ...
>         if (bat_priv->bla.claim_hash) {
>                 batadv_bla_purge_claims(bat_priv, primary_if, 1);
>                 batadv_hash_destroy(bat_priv->bla.claim_hash);
>                 bat_priv->bla.claim_hash = NULL;
>         }
>         ...
> }
> 
> leading to a use-after-free in batadv_bla_purge_claims() and a double free
> via batadv_hash_destroy()?
> 
> Would it be safer to set bat_priv->bla.claim_hash = NULL immediately after
> destroying it in batadv_bla_init()?
> 
> 

Completely out-of-scope for this patch. Submitted patch for review to 
https://patch.msgid.link/20260901-claim-avoid-err-double-free-v1-1-6d6f081f5151@narfation.org

Regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]