Re: [PATCH net 1/9] batman-adv: fix stale receive device on merged fragments

[Sven Eckelmann <sven@narfation.org>]

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

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260821094813.201800-1-sw%40simonwunderlich.de?part=1

> --- Patch [1]: [PATCH net 1/9] batman-adv: fix stale receive device on merged fragments ---
[...]
> On the receive side, batadv_bla_rx() is called from batadv_interface_rx()
> only after skb->dev has already been replaced:
> 
> net/batman-adv/mesh-interface.c:batadv_interface_rx() {
> 	...
> 	/* skb->dev & skb->pkt_type are set here */
> 	skb->protocol = eth_type_trans(skb, mesh_iface);
> 	...
> 	if (batadv_bla_rx(bat_priv, skb, vid, packet_type))
> 	...
> }
> 
> and batadv_bla_rx() does not call batadv_bla_process_claim() at all.
> 
> That leaves batadv_arp_get_type() in
> net/batman-adv/distributed-arp-table.c as the only consumer that can see
> the stale receive device of a merged fragment:
> 
> 	if (unlikely(!pskb_may_pull(skb, hdr_size + ETH_HLEN +
> 				    arp_hdr_len(skb->dev))))
> 
> reached via batadv_dat_snoop_incoming_arp_request()/_reply() from
> batadv_recv_unicast_packet()/batadv_recv_bcast_packet(), and only when
> CONFIG_BATMAN_ADV_DAT is built and bat_priv->distributed_arp_table is
> enabled.
> 
> Since this carries Cc: stable, would it be worth restating the affected
> path as DAT only, and mentioning that reaching it depends on DAT being
> compiled in and enabled?

No

Kind regards,
	Sven

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