On Fri, 24 Jul 2026 14:12:30 +0100 Simon Horman wrote: > [Severity: High] > ... does modifying the MAC header directly in hsr_xmit() corrupt > shared packet data? [...] > Should the skb be unshared before making these direct modifications?
I checked this against the v4 base and the series diff. The shared-data write is real. hsr_xmit() writes eth_hdr(skb)->h_source in place - the slave-address substitution for master-originated frames, and the macaddress_redbox substitution for the interlink port - on skbs that can be clones. Multiple consumers can share the same packet data while needing different source addresses: a PRP LAN broadcast or multicast can be delivered to the master (source rewritten via hsr_addr_subst_source()) and forwarded to the interlink (rewritten to macaddress_redbox) from the same underlying buffer. Two scope facts. This is pre-existing HSR RedBox code, present since v6.11: hsr_xmit() itself is untouched by the series (patch 1/4's hsr_forward.c changes sit below it and do not modify its body), and the series' only h_source-adjacent change moves an existing ether_addr_copy() a few lines earlier in hsr_dev_finalize(), where no skb is involved. But the series does make the existing interlink path reachable for PRP. I will handle this as an independent fix for the existing HSR/PRP code, posted separately for net with its own Fixes: tag - not folded into this feature series. Would you like the feature series to wait for that fix, or may v4 proceed while it is reviewed separately? (The hsr_create_tagged_frame() side question overlaps the third finding in your 3/4 mail; it is answered there.) -- Xin
