Re: [PATCH net-next 8/9] batman-adv: tt: reject VLAN/TT entries before reaching size limit

[Sven Eckelmann <sven@narfation.org>]

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

On Thursday, 1 October 2026 12:10:31 CEST netdev-bot+sashiko@kernel.org wrote:
[...]
> > Signed-off-by: Sven Eckelmann <sven@narfation.org>
> > Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> 
> [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

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