Hi Vladimir, Thanks for the review.
I checked the DSA cases with CONFIG_NET_DSA_LOOP=y. Since dsa_loop normally uses DSA_TAG_PROTO_NONE, I used a local repro-only override of dsa_loop_get_protocol() to select the relevant tagger, then sent an AF_PACKET/SOCK_RAW frame with PACKET_QDISC_BYPASS and sll_protocol=ETH_P_IP through lan1. That leaves skb->mac_header unset (65535) on the direct-xmit path. For tag_ocelot_8021q, the eth_hdr(skb) version reproduces as: BUG: KASAN: slab-out-of-bounds in ocelot_xmit() Switching that site to skb_eth_hdr(skb) makes the same reproducer run clean. I also checked the LAN937X path the same way by forcing DSA_TAG_PROTO_LAN937X. The eth_hdr(skb) version reproduces as: BUG: KASAN: slab-out-of-bounds in lan937x_xmit() and the skb_eth_hdr(skb) version runs clean with the same packet sender. So yes, for these DSA TX paths this is a real bug on the PACKET_QDISC_BYPASS path, not just a future-proofing cleanup. I have not yet checked ibmveth with a pseries/ibmveth setup. For the older DSA commits you listed, I think they should be treated as stable candidates if they remove eth_hdr()/skb_mac_header() use from the same TX path. I can go through those individually and send a follow-up with the exact stable list if that would be useful. Thanks, Doruk On Mon, 13 Jul 2026 23:04:17 +0300, Vladimir Oltean <[email protected]> wrote: > On Mon, Jul 13, 2026 at 09:40:08PM +0200, Doruk Tan Ozturk wrote: > > ocelot_xmit() reads the Ethernet header via eth_hdr(skb) to test the > > destination address against the link-local range. > > > > On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb > > reaches ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) > > resolves to skb->head + (u16)~0 and the read is out of bounds. > > > > On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), as > > done for the same class by > > commit f5089008f90c ("macsec: don't read an unset MAC header in > > macsec_encrypt()") > > and commit 96cc4b69581d ("macvlan: do not assume mac_header is set in > > macvlan_broadcast()"). > > > > Fixes: 43ba33b4f143 ("net: dsa: tag_ocelot_8021q: fix inability to inject > > STP BPDUs into BLOCKING ports") > > Cc: [email protected] > > Found by 0sec automated security-research tooling (https://0sec.ai). > > Assisted-by: 0sec:claude-opus-4-8 > > Signed-off-by: Doruk Tan Ozturk <[email protected]> > > --- > > Reviewed-by: Vladimir Oltean <[email protected]> > > I was not aware of the bug introduced by commit d346a3fae3ff ("packet: > introduce PACKET_QDISC_BYPASS socket option"). Commits > eabb1494c9f2 ("net: dsa: tag_ocelot: do not rely on skb_mac_header() for VLAN > xmit") > 499b2491d550 ("net: dsa: tag_ksz: do not rely on skb_mac_header() in TX > paths") > f9346f00b5af ("net: dsa: tag_sja1105: don't rely on skb_mac_header() in TX > paths") > 0bcf2e4aca6c ("net: dsa: tag_ocelot: call only the relevant portion of > __skb_vlan_pop() on TX") > > were made assuming that the bug to avoid would be exclusively a future > one (the revert of commit 6d1ccff62780 ("net: reset mac header in > dev_start_xmit()")) and thus they were not marked as bug fixes. > > Are they true bug fixes, as in "can we reproduce these [using > CONFIG_NET_DSA_LOOP=y on virtually any network adapter]"? If so, should > all the commits above also be backported to stable?
