From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 AE00933A9E8 for ; Thu, 18 Jun 2026 19:00:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781809245; cv=none; b=SSsBwTcQcdbmGHbhdzBL2U1eam1JLFambUmLdLj3Yu0eeFDz40MfDk9l1Z9+0mdOWjGahi2P4HnpBfLa8jJa0t8RRvf0vax3cVvKrZlEiYiVhad9FdVo21uk+mG4puB7leOm6NN7DdnUjk45qsw9+/1PmdioO4F1unUV54qQpLs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781809245; c=relaxed/simple; bh=8kJMz9LKQ/8hfHjif49visLmKVnF4eIjhO0ToUzckXw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PUfkHVNfAUqDTwSl9co8BdnFDybCZYDihZi6JJRVSqAHWFmboxe9CXfDCsMgKoqAEEbFrsQx1D/OKMXPaOG7tn3Ra9AMtRDHOlhJOz5S2yc3vkTVAfW1Lv4QTvLxJZdtSv2vPI77X3aEEn6R+VaX/+uBx50fDpn5OnYWOFyI5y8= 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=MFKNZsJG; arc=none smtp.client-ip=209.85.216.42 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="MFKNZsJG" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-36baeec21dcso792612a91.3 for ; Thu, 18 Jun 2026 12:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781809243; x=1782414043; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=KZJIVkKgNSYCGOK4bX9+88PTNdyEosGt30DWnvoVWjY=; b=MFKNZsJGybN51u5DlLE3vuL/c+ZASTuwQ8136Wh7+E648ocRlI9D91DTdsuiTrhVYr 3FxYFqxZhNebkQggoHO6yNw7/2krANRroyNy1Z7peuTTVQYe7yeRDyucuxfRbzEaADMM qALQKFKCDK6T+uDuocjggyLSfjj94Etl14EvJJHX2LAs+jR8aCTE7oiyNmCCjKfONBfy sRzXc0aw8JIfWf8BgwJMbDiNHN+W9J8AL1tFC950NJ+FLgSPOlhsBXrPGtiHiNmgrbMF sMz8NKBEbnBdHW5+KF2DRp8pFgmemEcjRrNTCDWxVHyheBdY2lAWWIjV7QDlE/83Y+ke +XeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781809243; x=1782414043; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KZJIVkKgNSYCGOK4bX9+88PTNdyEosGt30DWnvoVWjY=; b=PPVWpAQDxYnPjgiJQrP9RSNNk2oMS7LcxbBXaYE3/WcP2EOoAspOJ478CzsVxk8uMJ 5vEg+la68aY4KlWcV1AqZXDZwfUE1uh1aR1MJXTqULc8Cx1Glf8RyEAFyQyCIzHnj7TD HhO3qkJx/aT7Igau9/lGrSqUm1DZFAQ3+jYzczffNjcFrv85/AOMbAT5263+jqeR3kOB B2/kKDLUiCAiTLj8h/4dhPtRhWYN7PmjrjEzTbPtY520P7wnUM96xGzQKRJB8CvXqqUF 9GdSPhdLKsN97llkJkIcBbm37sTfCRYFtfWC09Hum56r8XyHwQzM2xdzTqhvtyXHDVoT a4xw== X-Forwarded-Encrypted: i=1; AFNElJ+q8NPrfzg6WOT+kfzQem+iQTKA1iIgqxD/ueemfrhX7YNSZp8Kyh6dofMZqqVNT1xJvQMcHsQy+TVyVvw=@vger.kernel.org X-Gm-Message-State: AOJu0YzVLtGYLwCEKz/mIicS60KGHkO/7cn8ZemE6QK8BdByJSSrJ1dJ JMyOdhSrCzD9P59zfTGWQzfWod50vkwoN3J6G1QQahoCCxoRebsYZzQ5yVrcUw== X-Gm-Gg: AfdE7ckmF/41USNi0tiEGzjtsdgMEyvVA7vf4jBIOwy+jRYoFIxAi9p9rpg30iB8PHL sBxy4tA7I0YRfdmR801sURbLIVdwD3qbAFR+6C8YRaVCp01vRMYFS1Qc5b97kTsV3YoE/2Zt3Ou 5tBYomkKUgA+ct/ySRcN39H8rnKO5XmpwxBKYEW6450J5zkCgbpYfdiUpP5b/FQCUXfnkGlgR6a DesllII0+wcFTR2p09oKbVu8/LnxtBORMRf4JzpHz3pnMecWTrmEjElMSJiKPJWZ8mGpev/ku/U WMOA5mJDU1iAtXKpKDzBqG5koziBtBQgET5bC9Fc2g9w6ceANDZkmcYW5z3x+3SbpFSAJvrh/hD h0z4Nb7UTryKU1AaIGTy57GkddSljeH5IJ7Bd2epBO093YnUcOutum3WgoEdzVOkatC/F7QdIl+ B5lK+u33hUmQ== X-Received: by 2002:a17:90b:5103:b0:369:2e00:1ff0 with SMTP id 98e67ed59e1d1-37d15e170e3mr781639a91.6.1781809242899; Thu, 18 Jun 2026 12:00:42 -0700 (PDT) Received: from john-p8 ([98.97.43.82]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-37d1aa48f04sm25097a91.2.2026.06.18.12.00.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 12:00:42 -0700 (PDT) Date: Thu, 18 Jun 2026 12:00:40 -0700 From: John Fastabend To: Sechang Lim Cc: Jakub Sitnicki , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Liu Jian , Daniel Borkmann , Cong Wang , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH bpf] bpf, sockmap: fix BUG_ON in skb_to_sgvec() on a resized ingress skb Message-ID: References: <20260613082442.3252576-1-rhkrqnwk98@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260613082442.3252576-1-rhkrqnwk98@gmail.com> On Sat, Jun 13, 2026 at 08:24:31AM +0000, Sechang Lim wrote: >sk_psock_skb_ingress_enqueue() maps a received message into a scatterlist >with skb_to_sgvec(skb, sg, off, len). On the SK_SKB strparser path off and >len come from the message's strp_msg (stm->offset and stm->full_len), set >by the stream parser. strparser does not trim the skb, so normally >skb->len - off >= full_len and len is within the skb. > >An SK_SKB verdict (or parser) program may call bpf_skb_change_tail() and >shrink the skb after full_len was recorded. len then covers more bytes than >the skb holds, __skb_to_sgvec() walks past the data and trips BUG_ON(len): FWIW this only happens if the strparser program is also attached. If there is no strparser program stm->offset = 0 and stm->full_len will be whatever the verdict program set. So there we would get len = skb->len; // then if it shrinks to skb->len - X its ok. off = 0; > > kernel BUG at net/core/skbuff.c:5286! > RIP: 0010:__skb_to_sgvec+0x78c/0x790 > Call Trace: > > skb_to_sgvec+0x32/0x90 > sk_psock_skb_ingress_enqueue+0x42/0x370 > sk_psock_skb_ingress_self+0x1a8/0x200 > sk_psock_verdict_apply+0x33c/0x360 > sk_psock_strp_read+0x24a/0x370 > __strp_recv+0x66d/0xda0 > __tcp_read_sock+0x13d/0x590 > tcp_bpf_strp_read_sock+0x195/0x320 > strp_data_ready+0x267/0x340 > sk_psock_strp_data_ready+0x1ce/0x350 > tcp_data_queue+0x1364/0x2fd0 > > >Clamp len to skb->len - off, and drop the message if off is already past >the skb. sk_psock_skb_ingress_enqueue() is the only skb_to_sgvec() caller >and both ingress paths (verdict SK_PASS and the backlog worker) reach it. >The clamp is a no-op unless the skb was shrunk. > >Fixes: 7303524e04af ("skmsg: Lose offset info in sk_psock_skb_ingress") >Signed-off-by: Sechang Lim >--- > net/core/skmsg.c | 4 ++++ > 1 file changed, 4 insertions(+) > >diff --git a/net/core/skmsg.c b/net/core/skmsg.c >index e1850caf1a71..2961178ebd1e 100644 >--- a/net/core/skmsg.c >+++ b/net/core/skmsg.c >@@ -550,6 +550,10 @@ static int sk_psock_skb_ingress_enqueue(struct sk_buff *skb, > { > int num_sge, copied; > >+ if (off >= skb->len) >+ return -EINVAL; >+ len = min_t(u32, len, skb->len - off); >+ This is blocking the BUG but will break the socket. We should fix at the cause. Something like this untested... although I've never used the strparser program in any of our cases. diff --git a/net/core/skmsg.c b/net/core/skmsg.c index 2521b643fa05..95347f9d140c 100644 --- a/net/core/skmsg.c +++ b/net/core/skmsg.c @@ -542,6 +542,20 @@ static struct sk_msg *sk_psock_create_ingress_msg(struct sock *sk, return alloc_sk_msg(GFP_KERNEL); } +static bool sk_psock_skb_strp_range(struct sk_buff *skb, u32 *off, u32 *len) +{ + struct strp_msg *stm = strp_msg(skb); + + *off = stm->offset; + if (unlikely(*off >= skb->len)) { + *len = 0; + return false; + } + + *len = min_t(u32, stm->full_len, skb->len - *off); + return *len; +} + static int sk_psock_skb_ingress_enqueue(struct sk_buff *skb, u32 off, u32 len, struct sk_psock *psock, @@ -696,12 +710,8 @@ static void sk_psock_backlog(struct work_struct *work) while ((skb = skb_peek(&psock->ingress_skb))) { len = skb->len; off = 0; - if (skb_bpf_strparser(skb)) { - struct strp_msg *stm = strp_msg(skb); - - off = stm->offset; - len = stm->full_len; - } + if (skb_bpf_strparser(skb)) + sk_psock_skb_strp_range(skb, &off, &len); /* Resume processing from previous partial state */ if (unlikely(state->len)) { @@ -709,6 +719,9 @@ static void sk_psock_backlog(struct work_struct *work) off = state->off; } + if (unlikely(!len)) + goto out_free_skb; + ingress = skb_bpf_ingress(skb); skb_bpf_redirect_clear(skb); do { @@ -737,7 +750,8 @@ static void sk_psock_backlog(struct work_struct *work) len -= ret; } while (len); - /* The entire skb sent, clear state */ +out_free_skb: + /* The skb has been handled, clear state. */ sk_psock_skb_state(psock, state, 0, 0); skb = skb_dequeue(&psock->ingress_skb); kfree_skb(skb); @@ -1020,10 +1034,10 @@ static int sk_psock_verdict_apply(struct sk_psock *psock, struct sk_buff *skb, len = skb->len; off = 0; if (skb_bpf_strparser(skb)) { - struct strp_msg *stm = strp_msg(skb); - - off = stm->offset; - len = stm->full_len; + if (unlikely(!sk_psock_skb_strp_range(skb, &off, &len))) { + err = 0; + goto out_free; + } } err = sk_psock_skb_ingress_self(psock, skb, off, len, false); }