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