net: don't read an unset MAC header on the raw/qdisc-bypass TX path

[PATCH net 0/3] net: don't read an unset MAC header on the raw/qdisc-bypass TX path

Posted by Doruk Tan Ozturk 1 week, 5 days ago

On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path, skb->mac_header
is left unset when ndo_start_xmit() runs, so eth_hdr(skb) resolves ~64KB out of
bounds. Commit f5089008f90c ("macsec: don't read an unset MAC header in
macsec_encrypt()") fixed one instance; these three are the same class in other
TX/.xmit paths, each reading eth_hdr(skb)->h_dest. On TX the L2 header is at
skb->data, so use skb_eth_hdr() (a no-op on normal TX where mac_header is set).

Found by static analysis (0sec); verified against source, not runtime-reproduced.
Confirmed by an independent cross-check that mac_header is unset on the bypass
path (__dev_direct_xmit does not reset it). More siblings exist (sja1105 shared
TX/RX helper, atlantic PTP path) and will follow separately.


Doruk Tan Ozturk (3):
  net: dsa: tag_ocelot_8021q: don't read an unset MAC header on transmit
  net: dsa: tag_ksz: don't read an unset MAC header in lan937x_xmit()
  ibmveth: don't read an unset MAC header on transmit

 drivers/net/ethernet/ibm/ibmveth.c | 2 +-
 net/dsa/tag_ksz.c                  | 2 +-
 net/dsa/tag_ocelot_8021q.c         | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.43.0

Re: [PATCH net 0/3] net: don't read an unset MAC header on the raw/qdisc-bypass TX path

Posted by Jakub Kicinski 3 days, 3 hours ago

On Mon, 13 Jul 2026 21:40:07 +0200 Doruk Tan Ozturk wrote:
> On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path, skb->mac_header
> is left unset when ndo_start_xmit() runs, so eth_hdr(skb) resolves ~64KB out of
> bounds. Commit f5089008f90c ("macsec: don't read an unset MAC header in
> macsec_encrypt()") fixed one instance; these three are the same class in other
> TX/.xmit paths, each reading eth_hdr(skb)->h_dest. On TX the L2 header is at
> skb->data, so use skb_eth_hdr() (a no-op on normal TX where mac_header is set).
> 
> Found by static analysis (0sec); verified against source, not runtime-reproduced.
> Confirmed by an independent cross-check that mac_header is unset on the bypass
> path (__dev_direct_xmit does not reset it). More siblings exist (sja1105 shared
> TX/RX helper, atlantic PTP path) and will follow separately.

If there's one known source of such strange packets we generally try to
fix the problem at the source rather than hardening the whole stack
against bad packets.

Can we make SOCK_RAW + PACKET_QDISC_BYPASS set the header offset
instead? (If not the relevant analysis should be part of the cover
letter).
-- 
pw-bot: cr