From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f54.google.com (mail-yx1-f54.google.com [74.125.224.54]) (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 E7C221E0B9C for ; Mon, 3 Aug 2026 01:33:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.224.54 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785720790; cv=pass; b=XUvTsu+g1Avwgpt4++4D/asSoekvJlS6OM5XU6wQ9525q3U4E6BCx5TZbnxSFTquO0guheYUH7zukCxc5V50yLYaQGMIUzsLZ4MpuflZGcnsnKMErFoWpa1xAfNTakW45YAuDgDAr7XSjuKZe/6R8yudGuGPvfvvvigw9SikQdA= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785720790; c=relaxed/simple; bh=hdzmpEyx7wmQQes5tKR6PInw0TXRMu3tnEXMX3bv/zo=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nBKahKGhWut84ZD0e0ULQ6TultpA6wQCAmKrdfLv0M+Rjmb/BMJdN+f9US320R4CyoNQBdZBG0fi+9/ES1JMLaMzlkHieFxT/PaHK6WZYThBGFBN1dpR1KnB9qGVgKeKc8Dsoi7uCwPtqFWRlCVbikDux589Exz7hOFJ/dJia0c= ARC-Authentication-Results:i=2; 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=cxff5bxN; arc=pass smtp.client-ip=74.125.224.54 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="cxff5bxN" Received: by mail-yx1-f54.google.com with SMTP id 956f58d0204a3-664e3ed58bcso5219230d50.1 for ; Sun, 02 Aug 2026 18:33:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785720788; cv=none; d=google.com; s=arc-20260327; b=s/Yh4nuKZ8tXpW8KL46LnemqDasZlTWAy28Lj9A4/ylRG62d/NEA+BNh8iWVyAUSfn zti7GNcrrqRR71cJlwyhglRB0uhca7j1gD2vB10QpXbYq5H3RsgdO7JHTv9O7gY/fw/E zwNpeG/5yI6O+ER0wnCjrvSaGE33y+B+ZcsrGdVrDJdofo1g37w3TIHZbht+u0l/5Q7x GU7O0nd3+L+OgiVwiAPfCEzakw5LHMtIn0NZGIko9//rM6eL4FqWCdQU5jHVRoLI2XWn m7u2wd3iaDr7yyK7wrpgX8RbYgwI/mheusqLs+7L0UhbIwRi6KUw8kuo+/zLsiSHkv6J owhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=MtK1QoBX9EhvBSeTPFcat/a++KIi/D9hUCf5F/tRn3Q=; fh=AvKQd5qZ8VwyNwocyZtSnQ06LOK4vMbRjfMk5FrE9i0=; b=szf//8MrEJWdQs+Pd2oFWzF0Ib19edoe574TmSv0kIZgTC3xKDxvdWr2YqGp+DaEY7 t9KmiUibwoxxSVh921eqnOJQebNHNPwB3jWQmMBshmwLT1luUfDR1KqryyZU9wvghqCk MjI5ofeBZ1m5e/8Tbe0PYu8XKuEqkArnyN91ouNcB5bcfnPbwBHio3DKrE6PGofGswlF 8pS2DBR4dl4GkJItPUJjJ668UAponuVmJadIyNhtS6L9j0WngJLvhDWPnc6ZjqGccuPQ KacJcXlQYohnMFcARWosOJ8DQucaSIM1TARCrmyR1uGB9wyokmd3lkwRJIQK+1SXDu3Y trAw==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785720788; x=1786325588; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=MtK1QoBX9EhvBSeTPFcat/a++KIi/D9hUCf5F/tRn3Q=; b=cxff5bxN1mY09Ynidyu/GMTgRqPWYllE/6HBQFWqHZcbPtqslT5JTtOBdmC9TBuZOf 1bBgNZL8QMdvjEK/ElzPsc4OKbrdzEFp51sDg2rONC/2owAbQezeCmizO0SAAyTf0DqV M/9SeWk2k2+8x7E0bml1Nv6c4g7VYcisoML9qADMIz92rSaODAuwE4STfQz5MpZYBGTo NIh5yFzEpOWEh7007NfpNxZ6bD9ifWSOw4iyqR1OyMfXnNku/WBgWgsyhlgMJZUvp6cS whaG8TLhzQR1+w8HdXXwThdc/OqrtgXUXkXv2VDutoG+tcVznTkYcgda/Dl4ei+lngSq lEHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785720788; x=1786325588; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=MtK1QoBX9EhvBSeTPFcat/a++KIi/D9hUCf5F/tRn3Q=; b=qgErOI3pUZG0qtUVw7bcH6OFpZLuHO9EA7e5rGTZ2fNfTSpBcfoVerYJ+Z+77DEkum njlED34CHe53wa1i2/+rtvdWZzYb2FW3JVWSRbRAxGRGGotbTIuhHznKZjHJ6WXUBKSb xo9GAQOudR/4MdHu4kSqQaG5j92eC+dh6UwW9lRwqucZP2xxuYkszBO6TSD2vbsp/Msm rEPmg+N7DsCmE/pCl/7H7NswuQK41V9ymolOiyR4d1E3plaZBE/sPydAq5Up7Q4JLXzF yAf6gDM2s0DptO0AvXK1otnFKBgeeV9nYaY3niBP0rBXdUFtsGYI+/ubipwJBmkrF7dg 612g== X-Forwarded-Encrypted: i=1; AHgh+RoKXKqqN5o6lcMpZaTraZH6am7LEDztWSvjF0o9p4GJfCMuy7oryNyRirjaZYaOtn2DMLt0GLyweCYSIKI=@vger.kernel.org X-Gm-Message-State: AOJu0Yyv+NoCnPoptM3R+Jqyrean/fa20YEdJCnhtD5Wgw6RwCWJ98Yz udwzTWtHiYI47x4MKMl6mgYOrFPpVp5Rs/pD59OD1+h18y9BcwTX5+S0wF/OvrcqWojaydIE8jV WkRakPUjkr3XDbFCluKug7GOCinW7Y9M= X-Gm-Gg: AR+sD13IOxVLCaFNBdqYU7GYgpGkqmTR4ZE0RZ/J14CdGL6xYXl/7brRpkYCs4usF6B GfvMb04uqHhb59QcSMqGu+tLCpTA9oPJLHiuAK3OGvOr7bEE7Tw5byP7j6wf7n35lhdMnS1AUbr 3VcHRJ8mzazqVGHiJd28+bgra+Y1+9eAWgbXs0LqCi+Vze6TSitmXXvGqcXSgeBPCLGeYsqvJPf UpIdvclQfeHJaLfj4r6CSKP8iK7is4UcXZ/9AHL/+2i3wZmbWNcnt+uy9so3IYNjeUlHVcwv1EX NyvcRv4RrMusvUHEW44jueTV+/QqQgzz4+dSlpySxmYegXtw74io2+oCADjFjuzZ6J3iFXoXtpv Yxby2DpEgVGRv56YAGAyxe3c/ X-Received: by 2002:a53:e031:0:b0:667:8471:41a2 with SMTP id 956f58d0204a3-6694f9ec735mr7732211d50.25.1785720786742; Sun, 02 Aug 2026 18:33:06 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260731032357.6114-1-sun.jian.kdev@gmail.com> <20260731032357.6114-3-sun.jian.kdev@gmail.com> <80687d9c-9c27-494c-b3f2-efd0230b1895@gmail.com> In-Reply-To: <80687d9c-9c27-494c-b3f2-efd0230b1895@gmail.com> From: sun jian Date: Mon, 3 Aug 2026 09:32:56 +0800 X-Gm-Features: AUfX_my1NUSs3oqdmWxM7iAAroMNTq7trteihXH_7Nm5heweklKCXTUafeNBAzw Message-ID: Subject: Re: [PATCH net v2 2/2] veth: fix skb length accounting after XDP frag adjustment To: Mohsin Bashir Cc: netdev@vger.kernel.org, Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Kuniyuki Iwashima , Hangbin Liu , Krishna Kumar , Samiullah Khawaja , Martin Karsten , Lorenzo Bianconi , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, maciej.fijalkowski@intel.com, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 1, 2026 at 12:14=E2=80=AFAM Mohsin Bashir wrote: > > > > On 7/30/26 8:23 PM, Sun Jian wrote: > > veth exposes non-linear skb fragments through an xdp_buff. If an XDP > > program adjusts the fragment area, veth_xdp_rcv_skb() copies > > xdp_frags_size back to skb->data_len but leaves skb->len containing the > > old fragment contribution. > > > > After a fragment shrink, this makes skb_headlen() larger than the actua= l > > linear area. In the reproduced UDP receive path, __skb_datagram_iter() > > copied 1024 bytes past the actual linear tail to userspace, starting at > > struct skb_shared_info. The copied bytes included the affected skb's > > nr_frags, xdp_frags_size and a kernel pointer from > > skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same > > amount and truncated at the end. > > > > Subtract the old data_len before replacing it and add the new data_len > > afterwards, keeping skb->len and skb->data_len synchronized. > > > > The fragment accounting must run before the linear tail adjustment: > > when bpf_xdp_adjust_tail() shrinks the packet into the linear area it > > releases all fragments, and __skb_put() requires skb->data_len =3D=3D 0 > > by that point. > > > > A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened b= y > > 1024 bytes from its fragment area. Before the fix, all 10 runs produced > > corrupted payloads. After the fix, all 10 runs matched the expected > > payload exactly. > > > > Fixes: 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order to accept = non-linear skb") > > Cc: stable@vger.kernel.org > > Link: https://lore.kernel.org/bpf/al9T9Eto%2FhRIzP5W@boxer/ > > Signed-off-by: Sun Jian > > --- > > drivers/net/veth.c | 23 +++++++++++++++-------- > > 1 file changed, 15 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > > index 00e34afd858e..348391e87e14 100644 > > --- a/drivers/net/veth.c > > +++ b/drivers/net/veth.c > > @@ -865,18 +865,25 @@ static struct sk_buff *veth_xdp_rcv_skb(struct ve= th_rq *rq, > > > > skb_reset_mac_header(skb); > > > > - /* check if bpf_xdp_adjust_tail was used */ > > - off =3D xdp->data_end - orig_data_end; > > - if (off !=3D 0) > > - __skb_put(skb, off); /* positive on grow, negative on shr= ink */ > > - > > /* XDP frag metadata (e.g. nr_frags) are updated in eBPF helpers > > - * (e.g. bpf_xdp_adjust_tail), we need to update data_len here. > > + * (e.g. bpf_xdp_adjust_tail). Remove the old fragment contributi= on > > + * from skb->len before updating data_len, then add the new one b= ack. > > + * This must precede the linear tail adjustment below: a changed > > + * data_end implies that no fragments remain, and __skb_put() req= uires > > + * a linear skb. > > */ > > - if (xdp_buff_has_frags(xdp)) > > + skb->len -=3D skb->data_len; > > + if (xdp_buff_has_frags(xdp)) { > > skb->data_len =3D skb_shinfo(skb)->xdp_frags_size; > > - else > > + skb->len +=3D skb->data_len; > > + } else { > > skb->data_len =3D 0; > > + } > > + > > + /* check if bpf_xdp_adjust_tail was used */ > > + off =3D xdp->data_end - orig_data_end; > > + if (off !=3D 0) > > + __skb_put(skb, off); /* positive on grow, negative on shr= ink */ > > > > skb->protocol =3D eth_type_trans(skb, rq->dev); > > > > I am most likely missing something here but what happens if we have > frags and we attempt to advance data_end while leaving some frags > present (e.g., bpf_xdp_pull_data())? Looks like, in that case we would > issue __skb_put(skb, off) with off > 0 and we would hit > SKB_LINEAR_ASSERT() because skb is still non-linear? Hi Mohsin, Thanks for catching this. You're right that bpf_xdp_pull_data() can advance data_end while leaving frags present. I'll investigate this path and follow= up. Thanks, Sun Jian