On Tuesday, 27 October 2026 09:55:24 CET netdev-bot+sashiko@kernel.org wrote:
> [Severity: Low]
> 
> Does this Fixes: tag point at the commit that introduced the problem?
> 
> 85fb027f611b removed a check from batadv_tt_local_create() that already
> limited the table by packet_size_max only:
> 
> -       /* Ignore the client if we cannot send it in a full table response. 
*/
> -       table_size = batadv_tt_local_table_transmit_size(bat_priv);
> -       table_size += batadv_tt_len(1);
> -       packet_size_max = READ_ONCE(bat_priv->packet_size_max);
> -       if (table_size > packet_size_max) {
> 
> That older check had no cap at the 16-bit tvlv_len either. So the missing
> limit seems to predate 85fb027f611b.
> 
> Blame on the parent of 85fb027f611b points at defa87f5ce75fe
> ("batman-adv: tt: extract allocation of new local entries"). That commit
> only moved this code, so the check is older still. The original commit
> was not identified.
> 
> Kernels without 85fb027f611b can still let the local table grow past what
> one unicast TVLV full table response can carry. This happens with
> fragmentation disabled and a hard interface MTU above
> sizeof(struct batadv_unicast_tvlv_packet) + U16_MAX. In that case,
> batadv_tt_prepare_tvlv_local_data() hits its check_add_overflow() path and
> returns 0, so no response is sent.
> 
> With the current tag, stable tooling would only pick this fix for trees
> that contain 85fb027f611b. Could the tag name the commit that first added
> the packet_size_max-only check? Or could the commit message say that
> older trees are affected too?
> 

The code only does it job partially after this commit. All of the previous 
commits would need a big revamp of the TT code - which is not backport-able 
via stable.

The really relevant part is in batadv_tt_local_reserve() and this was only 
introduced with this specific commit. And only for this commit, Sashiko 
pointed this out.

Regards,
	Sven