From nobody Fri Jul 24 05:21:57 2026 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5476323AE9B for ; Thu, 23 Jul 2026 02:03:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784772224; cv=none; b=RH2sDFIVvveqCi2wUNGAVH9VWVabWQscBZ/93hf2XzG895zCITcRA1IesHE2jpliMTf0jVCotDekBLEgpyLxZwAcDqH3+wwr5d+bor/DEHKBIxONghioLrF1G1/Bxhjb2bDbHAMWBC34AJIAROab2v0mRniwUIc67kxGfhADgQs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784772224; c=relaxed/simple; bh=DTnsess464JCWX4Jjgs591uOfQLF3+fEsBGSVAKwjCs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=fMfI/4YpdTNz4HyvvLxEwrQH0SZLqnUT9D0GaLcols2I8zii+lAURHbV3eg5dNIymt5f0s9USdy8PpwWrEQM6wf9BqZgC1idk4ri33SHCe3XKL9QPayd4R6Xs834XJQli7U8DezwfkEAw2F5QYmxpRRRT/Oymo/x+VYZ8ccZxII= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=0sec.ai; spf=pass smtp.mailfrom=0sec.ai; dkim=temperror (0-bit key) header.d=0sec.ai header.i=@0sec.ai header.b=RSu72PHI; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=0sec.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=0sec.ai Authentication-Results: smtp.subspace.kernel.org; dkim=temperror (0-bit key) header.d=0sec.ai header.i=@0sec.ai header.b="RSu72PHI" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-47640541585so34506f8f.1 for ; Wed, 22 Jul 2026 19:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=0sec.ai; s=google; t=1784772220; x=1785377020; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=FvT/D4ZKp7hg3WVh9nH1OIb3s4RjytZax6FVHwGekWw=; b=RSu72PHIggrhfelExSOh7Yck1oPnI3d+y5rpzIZIU7KA4c8aCbEiH4L3rxESJdjI1N zTlr424MfPMl9bSdg3O0dPGg9+TKSEHxahm0/F09c+LoaH8tvvykeGipYzR3ZxrloKLh kLW5/9Oo2XHGK1yX/F8avb8meChYnaSqr3vSgmYMwDvXR1xJSR6f1L4QrZUqzuPJTiyC 2Kercv52zku1+VpTG74Xw5hQnfyUwT/pYu4A+ulMjne5oFPdAbJFKdP5xr6sfDtjdncW N7USCV4YvP5ieWV+YcyoBAIR1unuk1l2aUneva8v4QV9iq5MnhSkixSy/Mb5C6AtcBi0 igng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784772220; x=1785377020; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=FvT/D4ZKp7hg3WVh9nH1OIb3s4RjytZax6FVHwGekWw=; b=N/tqdP8P+9a3/2vXhFN5io6MfzfTG7nrrGZL4cX3HhGSDc73VVHQwObd0p9DvDZeqf 8J7A7zELwpQbFlae3OXwMe2+RESXGGq0lIWlx02uZkB16DNYNz9bN0emsEWraJILROjE h90XOYYb90iloEyGjVnozLksvdBF7EgWseo/g9cGNRnHolc0Df9HtxYSKQxzYWbVL2GD TgtN7O0lGuhJGYJDwSr+6Cff5c5ZKOm9FQnqmPn70LlQ+B+CAg1b1byug9hORfU/F2VQ E/aAukmOl1tcL1CX/MVk+wQL1scuywYpZ90+YUyFk0/NRIi5yioUCb7Is2gNwMwX+VRE TQOQ== X-Forwarded-Encrypted: i=1; AHgh+RoxsyLHwQT6ov8hxn4fHr0EjpXHSCrvb9b3bAuOktO8mLkLBV9Gc8+bL0BAufil0Z63b/svQE/4AiImTXM=@vger.kernel.org X-Gm-Message-State: AOJu0Yzofv50bDlnt6qJslle2L/eaqwJ7Ia0p+d6sK18SdyrkPQNx+LG B4mrQpurT5nr0ii8IYfAr2yIQg95z2MqCeLxMZNWBap1AZivC8PgyfZqQIpXdoHjOrF6 X-Gm-Gg: AR+sD12WucwpS5GREPBnU5DHNKoa5Gt41/LMA9Qv01uG0gpkS+ikqkqRD9muVN5Dccj hOD9HwB1iEbRYuglHTilkgzyF8u+Ct0kPYEeALm5pU+75ZZLYVcWLZSuQcJ2Q0BLJAc+/SuUpwm HHdZTGMw2Cx2AWFOGPXFS0b/3w8irTFofIwfpIW2xqLYxG4QI+yYWuw4UHfW652TwRDbuaMIQ3W JkbC7NcYlTszgO6Q1ZbXh5LbmTNGkYOBCNZtNSxKu4ePqeVfN++gTJAf/+ywUHUXVRJkmj8dOZ3 98dcd0u0LxFina7+mQazBJ6Z2CwdoyKd5EMDtxuSlkj3nrKq71MuA36HP4iqA0jFdQZmCz2/WlJ Qm3cssMxHZhKB/m6ZRAn+x+TMy0kh4Y80MPTjMVhtFDZW85JmCKZAiZM2Y5r03Hd923kTWovptf 59Q5/vg1aoAQQgsu3hhKWm8t8RGQZw15E/ydsIRh/RJ5R6/zGinoz2YHL8chmytzLx11g+45Wc5 gxJiouCK4Oygt6U4FtA6PRi X-Received: by 2002:a05:6000:2387:b0:47f:6fbd:89eb with SMTP id ffacd0b85a97d-47f8dc936b1mr1300336f8f.57.1784772220232; Wed, 22 Jul 2026 19:03:40 -0700 (PDT) Received: from PeakBook-Mini.tail8e484.ts.net ([178.197.218.14]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85bb5a46sm10925157f8f.9.2026.07.22.19.03.38 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 22 Jul 2026 19:03:39 -0700 (PDT) From: Doruk Tan Ozturk To: Willem de Bruijn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Simon Horman , Sabrina Dubroca , Vladimir Oltean , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Doruk Tan Ozturk Subject: [PATCH net] net/packet: reset the MAC header on the packet-socket transmit path Date: Thu, 23 Jul 2026 04:03:37 +0200 Message-ID: <20260723020337.19040-1-doruk@0sec.ai> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol: if ((!skb->protocol || skb->protocol =3D=3D htons(ETH_P_ALL)) && sock->type =3D=3D SOCK_RAW) { skb_reset_mac_header(skb); skb->protocol =3D dev_parse_header_protocol(skb); } Every other outgoing packet-socket frame therefore reaches ndo_start_xmit() with the MAC header unset: a SOCK_RAW socket bound to a specific protocol (for example socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP))), any SOCK_DGRAM frame (its header is built by dev_hard_header(), which does not set mac_header), and the legacy SOCK_PACKET path. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access about 64 KiB past the head. This is the same class fixed for one consumer in commit f5089008f90c ("macsec: do not read an unset MAC header in macsec_encrypt()"); other TX .xmit paths that read eth_hdr(skb)->h_dest (several DSA taggers, ibmveth, sja1105, the atlantic PTP path) have the same problem. packet_parse_headers() runs only on the transmit path (packet_sendmsg_spkt(), tpacket_fill_skb(), packet_snd()), and there skb->data is the start of the L2 header for every packet-socket type. Reset the MAC header unconditionally so it is anchored for all of them, fixing the class at the source rather than hardening each consumer. The protocol probe is unchanged. A CONFIG_DEBUG_NET build stops warning about an unset mac header in skb_mac_header() on these paths, and the out-of-bounds eth_hdr() read no longer occurs. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested. Fixes: 75c65772c3d1 ("net/packet: Ask driver for protocol if not provided b= y user") Cc: stable@vger.kernel.org Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk --- This supersedes the per-consumer series "[PATCH net 0/3] net: dont read an unset MAC header on the raw/qdisc-bypass TX path" (https://lore.kernel.org/netdev/20260713194010.54642-1-doruk@0sec.ai/), per Jakubs suggestion to fix the problem at the source rather than hardening each driver. Vladimir Oltean had reviewed 2/3 of that series; this is a different (source) fix, so I have not carried the tags. net/packet/af_packet.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index e75d2932475a..adfb9c19a3ca 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -1924,11 +1924,21 @@ static void packet_parse_headers(struct sk_buff *sk= b, struct socket *sock) { int depth; =20 + /* + * packet_parse_headers() runs only on the transmit path + * (packet_sendmsg_spkt(), tpacket_fill_skb(), packet_snd()), where + * skb->data is the start of the L2 header for every packet-socket + * type: SOCK_RAW and SOCK_PACKET carry a user-supplied header and + * SOCK_DGRAM has one built by dev_hard_header(). Anchor the MAC + * header for all of them so a frame does not reach ndo_start_xmit() + * with the MAC header unset, where a driver reading eth_hdr(skb) on + * TX would dereference an out-of-bounds offset (skb->head + (u16)~0). + */ + skb_reset_mac_header(skb); + if ((!skb->protocol || skb->protocol =3D=3D htons(ETH_P_ALL)) && - sock->type =3D=3D SOCK_RAW) { - skb_reset_mac_header(skb); + sock->type =3D=3D SOCK_RAW) skb->protocol =3D dev_parse_header_protocol(skb); - } =20 /* Move network header to the right position for VLAN tagged packets */ if (likely(skb->dev->type =3D=3D ARPHRD_ETHER) && --=20 2.43.0