From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B58722EC096; Wed, 28 Jan 2026 15:38:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769614720; cv=none; b=GSvRArJWOhFW80pMeEmJfkfIiFzuoqFSgKvIor/G2wJ3cp+l8mLMBqAlb/CaQQXA/B5M+8iGdQ+Csrk4h7/PzWAxxIAQrKtsnRofI5CxryyXFPHUk0cbJlff//pKuJDb4F3IZMxWQVe4E/0PyrB7QF8WxcwtwHyvqymfdfhD5l4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769614720; c=relaxed/simple; bh=GHS/wrrsh13UViQLe63rmJ5LcFsnwaIlaeU5f21ZOVY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KminQqoIfkQsQbBY78+nKj9fQnI4t3OKoSzQ8vNAE4CwY4o+k0LXiWu25N2FHiLhUdJIxjvxBxhbDVvYyxL+zraEUIOaWcrTJQ5W6YvvdIM8F65joZH3tkqrXY351Nt5bTH3mKhKFInLu7d6tbjEigZz9Tp5B2AUAalYy6BLU7k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=oOvyjqYQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="oOvyjqYQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68A6FC4CEF7; Wed, 28 Jan 2026 15:38:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1769614719; bh=GHS/wrrsh13UViQLe63rmJ5LcFsnwaIlaeU5f21ZOVY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oOvyjqYQhueSpMgLqltMCvmXHWhFA3wEKwsrYCYF/mK9CeLspv0j7xrSPj3P3lltF a2+7j8iEFHJxqBeG7Qf/uek4/ZH/QAmay3NoHjyUkI+5p5AHuDSPihy1vmxtMoBDLb SKy4Uxolr8v7CnMTdBtIpq9I0CTBWQoGmcDsufTE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Yinhao Hu , Kaiyan Mei , Dongliang Mu , Daniel Borkmann , Martin KaFai Lau , Shung-Hsi Yu Subject: [PATCH 6.6 222/254] bpf: Do not let BPF test infra emit invalid GSO types to stack Date: Wed, 28 Jan 2026 16:23:18 +0100 Message-ID: <20260128145352.775480825@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260128145344.698118637@linuxfoundation.org> References: <20260128145344.698118637@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.6-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daniel Borkmann commit 04a899573fb87273a656f178b5f920c505f68875 upstream. Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there. Fixes: 850a88cc4096 ("bpf: Expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN") Fixes: cf62089b0edd ("bpf: Add gso_size to __sk_buff") Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Signed-off-by: Daniel Borkmann Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20251020075441.127980-1-daniel@iogearbox.net Signed-off-by: Shung-Hsi Yu Signed-off-by: Greg Kroah-Hartman --- net/bpf/test_run.c | 5 +++++ net/core/filter.c | 7 +++++++ 2 files changed, 12 insertions(+) --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -914,6 +914,11 @@ static int convert___skb_to_skb(struct s if (__skb->gso_segs > GSO_MAX_SEGS) return -EINVAL; + + /* Currently GSO type is zero/unset. If this gets extended with + * a small list of accepted GSO types in future, the filter for + * an unset GSO type in bpf_clone_redirect() can be lifted. + */ skb_shinfo(skb)->gso_segs = __skb->gso_segs; skb_shinfo(skb)->gso_size = __skb->gso_size; skb_shinfo(skb)->hwtstamps.hwtstamp = __skb->hwtstamp; --- a/net/core/filter.c +++ b/net/core/filter.c @@ -2451,6 +2451,13 @@ BPF_CALL_3(bpf_clone_redirect, struct sk if (unlikely(flags & (~(BPF_F_INGRESS) | BPF_F_REDIRECT_INTERNAL))) return -EINVAL; + /* BPF test infra's convert___skb_to_skb() can create type-less + * GSO packets. gso_features_check() will detect this as a bad + * offload. However, lets not leak them out in the first place. + */ + if (unlikely(skb_is_gso(skb) && !skb_shinfo(skb)->gso_type)) + return -EBADMSG; + dev = dev_get_by_index_rcu(dev_net(skb->dev), ifindex); if (unlikely(!dev)) return -EINVAL;