On Thursday, 1 October 2026 12:10:31 CEST netdev-bot+sashiko@kernel.org wrote: [...] > > Signed-off-by: Sven Eckelmann > > Signed-off-by: Simon Wunderlich > > [Severity: Low] > Should this have a Fixes: tag, and maybe a Cc to stable? No, the change is not suitable for stable backports. And since it is submitted for net-next, I am not allowed to add Fixes: (for old kernels) or Cc: stable@ tags. [...] > > diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c > > index 481dc6afaaba1..3349376a9087d 100644 > > --- a/net/batman-adv/translation-table.c > > +++ b/net/batman-adv/translation-table.c > > @@ -234,6 +234,162 @@ batadv_tt_global_hash_find(struct batadv_priv *bat_priv, const u8 *addr, > > [ ... ] > > > +static bool batadv_tt_local_reserve(struct batadv_priv *bat_priv, u16 num_vlan, > > + u16 num_entries, int *table_size) > > +{ > > + int packet_size_max = READ_ONCE(bat_priv->packet_size_max); > > + > > + scoped_guard(spinlock_bh, &bat_priv->tt.reserve_lock) { > > + bat_priv->tt.reserved_vlans += num_vlan; > > + bat_priv->tt.reserved_entries += num_entries; > > + > > + *table_size = batadv_tt_local_transmit_size(bat_priv->tt.reserved_vlans, > > + bat_priv->tt.reserved_entries); > > + if (*table_size <= packet_size_max) > > + return true; > > [Severity: Medium] > Can bat_priv->tt.reserved_entries wrap here? > > The new counters in struct batadv_priv_tt are u16. The only bound on them > is packet_size_max, and nothing caps packet_size_max at what a single TT > TVLV can hold. When fragmentation is disabled, batadv_hardif_min_mtu() > skips the clamp: This is actually a good point. I didn't think about the case of an extremely large MTU and used a 9000/64K MTU in my head as reason for using only u16. I still consider it as a corner case and will submit a follow up patch for it. > If packet_size_max is above roughly 65535, the table can still grow past > what batadv_tt_prepare_tvlv_local_data() can build, because tvlv_len is a > u16: > > if (check_add_overflow(*tt_len, change_offset, &tvlv_len)) { > tvlv_len = 0; > *tt_len = 0; > goto out; > } Correct, so widening over u16 doesn't make any sense. It seems to be better to just limit the size of the packet against which it is checked: Will be submitted later to netdev as follow up check because it is not a regression but just a limitation in the supported packet_size_max limits (for non-standard setups). https://lore.kernel.org/r/20261003-tvlv-limited-tt-response-reservation-v1-1-82fbca929cd9@narfation.org Regards, Sven