From nobody Tue Sep 29 07:39:37 2026 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 4174730EF80 for ; Tue, 11 Aug 2026 04:42:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786423321; cv=none; b=rBxnokqJVC8Ur6C1Jz7gzC6rcHNNnsnZJpgHXurWeZ+uzm4vAK7j9GkX31E/D34MculiVdSzcitWpWcfWycaVFBVWpfuXWYXStBXbBytZdfrqMLqWAZx1c3eXG8cIibGI2E2sZDn4x+S7Q9nAjR97x2GCPR0px+pZCArq3UG2Kw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786423321; c=relaxed/simple; bh=TYI3Ir+BDCYQue/6lV2LLRIUm7csBMdcONzm9C74S5I=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=qKxo02T/d1tTc53Wz5+CSMgCxbDbGoWW7dMvALwWdytQCGZT2wUoNoVqd2LIMpup+ijNmNfdlu12sGe/1pLWaLsvhnkECH2i2YHgRGgSK5OjBHdVdSs7IMCb+E3wWCuJwzdEByW6NiuVXD21milqL7UWf+5/DsXnMrCXabkFLvM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=M9cRgdUU; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="M9cRgdUU" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2cc61541f8cso7277395ad.0 for ; Mon, 10 Aug 2026 21:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786423319; x=1787028119; 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=X0Vsk37rDICdvEWMiRd9zBNv8uzJbopsS53qS1DBua0=; b=M9cRgdUUtFZW/pLfW8vxdjUGiLHvzAqKdTAyvn10/mTb0JRD+KFFpiKwUf/NJ8aSWU OU6rVOIwaMYRocvGChZ43DO2nqxr58XEF7DCC5QbZTKjfeXIvPGvwgvbxSrNiAkNldgm jGtxfbnZZraEdLIrSH/GHWpmn7H/9Nel0PZ4taV57T1XssX9vwuId4ga5J5s9GuM2fCU WwqejTtJ72JnV0OZkJrb4Id99PeEch8YUV23oaPP3zeM9X0u9aezy9jhlkbFP34huFJS 7CGgt+UJ1m55YUw3BvgqH0y/ThUKypsh5DhmTtupMESmsllxaaji8bb2v+DE4pIiTokF a1FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786423319; x=1787028119; 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=X0Vsk37rDICdvEWMiRd9zBNv8uzJbopsS53qS1DBua0=; b=pLtUm/dlMIwCmKcQ2XcSjMNsw2u9rSgONUA93NsHyXHkaEs0XvefwTtk0KvT0do1Jk CkZaJiWHatZVcBanytNTSUquHhtAYMRSzFkTC0E4syfeAHQGA9n04ZUOfM9ykPb69PUE fnQWlTHeCzW74OI1tILBb21ivmcY8VxHmX4HpQi9LhV416zOfDYTnbZwGlJXTZlKRecw 9vVPBRS6tEMMXtFKEdTjenznz3ZU4XG4xgwsb3tLsjWxoX1Xl7B0/wNlc/EuRXDZ09e6 bFQjCB7twtB4hOSnPSmPcpQvLkZ1sf/UWC8SUtp07iRlYtYmskSm4LJrAMabZWb5SCDf rxiw== X-Forwarded-Encrypted: i=1; AHgh+RpDesJw4L8/fD1GPIoZIaKk33OL/gXZsPao1uB93EwDq8te7XpUFpd1fjEaQnTn6Gg81dS9nOyUkf+4unI=@vger.kernel.org X-Gm-Message-State: AOJu0YxxYzHtS2iq6WrXvU0KMsUF6OAgHTGDamx1nB/0pe6IWBevVfXy cOEjqahXfNfwGwnWJA6bmw+naItTbxrSccy2fsPMtNmWggzPmU/4TDR7 X-Gm-Gg: AR+sD13aWv+HWiDnAHkwoV+l36oaa/WwSHUl7r3F8HqEcEmUuKU4Q64Nh03Sl3d53Cm HsSHENcewQVLGAstXXqTqtwGcsipShhXsyLpf+Ejpny5zh6lzmZ3APv1cJwPZ1cAqjaxYcsJRZP s3XhfVlBdpWG8pFhZr9A+IRMKWmAz2ViDx2Mfz3Ph5YmtSUofkp/Qvem+wjCwjuXkqrlktmZDMQ TYTiMIIjhSw+QKwo2luh4NX73CV+IA99ZUi8hgW+GpYk0kbqrm68OEDhqscceBk42FRZqMafHEH a3JEyyNvFGcoudvl1Nhq+LVjm5UwU1Kj9dukK2So/SFlGESbfpNm2K6QyRZC6LQ20lMA+1wAR0r Fxoq1wW/XyP7WRRTvCgo3ilRh/C+aFmQxIAma9uRDK1R+aceAmIMcfJNvOsekyQgbIMI49LY00M byWvx3wKnW3fz8PxyorZtDTDUd9rjwI+FqbUCEW93epOuGUlIdInf4Gjk= X-Received: by 2002:a17:903:1ce:b0:2cf:8aa7:7810 with SMTP id d9443c01a7336-2d318ed4f2fmr1383635ad.2.1786423319153; Mon, 10 Aug 2026 21:41:59 -0700 (PDT) Received: from omen-arch ([147.46.124.101]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d3160ce71csm1253695ad.52.2026.08.10.21.41.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2026 21:41:58 -0700 (PDT) From: Junseo Lim To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Simon Horman , Ido Schimmel , Martin KaFai Lau , Leon Hwang , Alexei Starovoitov , Guillaume Nault , Fernando Fernandez Mancera , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Graf , Sechang Lim , Emil Tsalapatis , Daniel Borkmann Subject: [PATCH bpf v2] lwt_bpf: restore reserved headroom after xmit program Date: Tue, 11 Aug 2026 13:41:49 +0900 Message-ID: <20260811044149.118235-1-zirajs7@gmail.com> X-Mailer: git-send-email 2.55.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" ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Reported-by: Sechang Lim Suggested-by: Daniel Borkmann Signed-off-by: Junseo Lim --- This issue was found by a custom fuzzer developed by Sechang Lim . Changelog: v1 -> v2: - Use LL_RESERVED_SPACE() instead of HH_DATA_ALIGN() to match the reservation made before LWT xmit. (Daniel Borkmann) - Add a Reported-by tag. v1: https://lore.kernel.org/all/20260727103005.897983-1-zirajs7@gmail.com/T/ net/core/lwt_bpf.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c index 652952d416f2..da49364ec63d 100644 --- a/net/core/lwt_bpf.c +++ b/net/core/lwt_bpf.c @@ -167,10 +167,10 @@ static int bpf_output(struct net *net, struct sock *s= k, struct sk_buff *skb) return dst->lwtstate->orig_output(net, sk, skb); } =20 -static int xmit_check_hhlen(struct sk_buff *skb, int hh_len) +static int xmit_check_headroom(struct sk_buff *skb, int hroom) { - if (skb_headroom(skb) < hh_len) { - int nhead =3D HH_DATA_ALIGN(hh_len - skb_headroom(skb)); + if (skb_headroom(skb) < hroom) { + int nhead =3D hroom - skb_headroom(skb); =20 if (pskb_expand_head(skb, nhead, 0, GFP_ATOMIC)) return -ENOMEM; @@ -282,7 +282,7 @@ static int bpf_xmit(struct sk_buff *skb) =20 bpf =3D bpf_lwt_lwtunnel(dst->lwtstate); if (bpf->xmit.prog) { - int hh_len =3D dst->dev->hard_header_len; + int hroom =3D LL_RESERVED_SPACE(dst->dev); __be16 proto =3D skb->protocol; int ret; =20 @@ -298,9 +298,12 @@ static int bpf_xmit(struct sk_buff *skb) return -EINVAL; } /* If the header was expanded, headroom might be too - * small for L2 header to come, expand as needed. + * small for the L2 header to come, expand as needed. + * neigh_hh_output() copies the cached header in + * HH_DATA_MOD aligned chunks, so match the reservation + * made before LWT xmit. */ - ret =3D xmit_check_hhlen(skb, hh_len); + ret =3D xmit_check_headroom(skb, hroom); if (unlikely(ret)) return ret; =20 --=20 2.55.0