From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f173.google.com (mail-dy1-f173.google.com [74.125.82.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 807FA4B8DF6 for ; Thu, 11 Jun 2026 16:28:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781195337; cv=none; b=PLgIltKZXFemBUqfbN8U9cByKSZ95HRxgLHn5Uog/O/i4IIbeDD9IhER/0eUdtz9I2ciLyp9ekf/UqnvH53PHP+oVWjezcXTBMkRhb3XOFWLXg+TWL1TzhdmvtFHCNrHaewY+MYguB92yMo1txVUpoxz24jlq1MqwpKxkmqpAg8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781195337; c=relaxed/simple; bh=Dq8U4JeMLdDJZCai9rkKpCchuv1uUA+lqZN3PGfqBIk=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=QfUi92R/TYvHp/qccIUQjvnzQCJpHU1MFy88Ky1n9GjmuN5gMkgQUyPb3ldAulwe1SEw4bKVx7p2m06XzPG2gGTjWEnj6HkD6TcUl+16/OkgNRNMa/qsC/EvGer81QP3wpWSXCK5iQ5OaC/6ZXPGqDGkObMFiSQExEneMxikq2Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com; spf=pass smtp.mailfrom=etsalapatis.com; dkim=pass (2048-bit key) header.d=etsalapatis-com.20251104.gappssmtp.com header.i=@etsalapatis-com.20251104.gappssmtp.com header.b=gO86XJ5l; arc=none smtp.client-ip=74.125.82.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=etsalapatis-com.20251104.gappssmtp.com header.i=@etsalapatis-com.20251104.gappssmtp.com header.b="gO86XJ5l" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-3074adb8fcaso173427eec.0 for ; Thu, 11 Jun 2026 09:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsalapatis-com.20251104.gappssmtp.com; s=20251104; t=1781195336; x=1781800136; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hmILQTIhg4C2xaf23uaTPKYf63Qsqb45amOoW42QXJM=; b=gO86XJ5lX2WhRMfkazLeKXLf7wv1CkXPx9mPNdIgUvnRG0+aMS1WTVPTkSFyz2/uju f+dl+CDOeVOGYozPh+AO0+g+AgA2I7Wj8aG25z9PsB5fyPphzH2PzL8g7p25qK12h4XW RE1fBgpAck3lEoD+tHqqnHXIFLFe91oecgiTgsV3/5L8YMOhIhmK+3xqnQ5wyeTr6DNp NveThIDMWV2oQieMoMTS/P4+oOR4X/CFU0JecME9HoQLWnVGGNzexXvEn+NmYX+57mMD 8/SRfSGfQ2vSlSUKCnOoHLyi5Jb8wCP3EWlntz/vDnyKTNzvb+FWamw5uieCRTuHLSlo G9Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781195336; x=1781800136; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hmILQTIhg4C2xaf23uaTPKYf63Qsqb45amOoW42QXJM=; b=Nm2H7ya8apotuieoYPNAq/1/Asx5cgHUYOKcMjYNceKqbdK9pNPOElwg84LcdpTO+V idUzrzKhAIpplkJHvh8iE5KSPFk3sFE4GnJzYm43pGkGpxL/5KXuC6O+7mnxIjrLpMDb vu3N80egJxfh8nKwVHdUExHytoT/0mM92fKaWCOgfwWBmifDqWVxd6hSZElRXos4A8m6 pnpRsCGboUJRFwOUFbRd1Uh7WCuZjSh4kEO1YTjPNsTeu5KfKRSgiQIe3i5QO5VoGfTq 6jdCFbghk0b/3GZKA70L4SYvCHnjBZ4/tfGz1hFu/yh87UKQvK2aHQlI7TASvNIXbTuB feFQ== X-Forwarded-Encrypted: i=1; AFNElJ8X1pjPlyg5b4yZAptgWhgR1PeccvsEpbaXkVOTLaf9AqsX/YyqKJBbzyxi7JWa3WzsVoL7FMca/2JH5OM=@vger.kernel.org X-Gm-Message-State: AOJu0YxSSoEH58a6OBu0Ckj2K0VC+a/n7a9KEJ4zkos7kaOh4yh6WqU4 JVizVTtmlzWZpSo17ibjPlCjV+iUKzZY1Y3zqWvusQ9S6Q6b/ooALuegDH5CZf3OnTk= X-Gm-Gg: Acq92OH9I8DKE9idSG+qfLSz1WU3Qohqm4VU64c1pLHRD6ReEaMlylrZVJdkle3Hdvl pHuPCYeaa8qCguQwYJT8BoZ0z5qfp1PLlTJRZBvSi+HOTZ1BwuECbejIVbQVRaVVaUWaKlneV3l mhWKX6S/7SQMoVvnj85jarCbLKIOfSXB1bGu2acIxNA3C7d1nARfb0BqHq1HjGqfHsP6X+gcqLj 221lmdwMGr1t3YawmUFd0xZGOusJAySOf3vipiBUa0E1ybKEKwHCFSpf30X0cO7+nTcIdpYZzrO BGCTY4quLeOcqJT192Yc0ec2HKAmr3XJirdPJNG08PO3canF+etMaD9oL8EJG3H8C0ANVfhhoId E9O9wy7oG3H4RLCH5ZOE3d3+GI1kCs19cYnmNgA+RCc8I+Pp8i4IRit2hS3rEII5bx4eu4CS39i aQGPft7DPdgyBEyp8= X-Received: by 2002:a05:7301:1292:b0:2fc:9ae6:e5a8 with SMTP id 5a478bee46e88-308049eb931mr2752590eec.20.1781195335328; Thu, 11 Jun 2026 09:28:55 -0700 (PDT) Received: from localhost ([2620:10d:c090:600::9f35]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30806c47afbsm3701418eec.10.2026.06.11.09.28.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2026 09:28:54 -0700 (PDT) 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 Date: Thu, 11 Jun 2026 12:28:51 -0400 Message-Id: Cc: "Weiming Shi" , "Xiang Mei" , "Daniel Borkmann" , "John Fastabend" , "Stanislav Fomichev" , "Martin KaFai Lau" , "Alexei Starovoitov" , "Andrii Nakryiko" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "Emil Tsalapatis" , "David S. Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Simon Horman" , "Jakub Sitnicki" , "Shuah Khan" , "Jesper Dangaard Brouer" , "Sechang Lim" , "Ihor Solodrai" , "Cong Wang" , , , Subject: Re: [PATCH bpf v2 2/7] bpf, sockmap: Fix wrong rsge offset in bpf_msg_push_data() From: "Emil Tsalapatis" To: "Jiayuan Chen" , X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260611123538.156005-1-jiayuan.chen@linux.dev> <20260611123538.156005-3-jiayuan.chen@linux.dev> In-Reply-To: <20260611123538.156005-3-jiayuan.chen@linux.dev> On Thu Jun 11, 2026 at 8:34 AM EDT, Jiayuan Chen wrote: > From: Weiming Shi > > When bpf_msg_push_data() splits a scatterlist element into head and > tail, the tail's page offset is advanced by `start` (absolute message > byte offset) instead of `start - offset` (byte position within the > element). This makes rsge.offset overshoot by `offset` bytes, pointing > to the wrong location within the page or beyond its boundary. Consumers > of the corrupted entry either silently read wrong data or trigger an > out-of-bounds access. > > BUG: KASAN: slab-use-after-free in bpf_msg_pull_data (net/core/filter.c:= 2728) > Read of size 32752 at addr ffff8881042f0010 by task poc/130 > Call Trace: > __asan_memcpy (mm/kasan/shadow.c:105) > bpf_msg_pull_data (net/core/filter.c:2728) > bpf_prog_run_pin_on_cpu (include/linux/bpf.h:1402) > sk_psock_msg_verdict (net/core/skmsg.c:934) > tcp_bpf_send_verdict (net/ipv4/tcp_bpf.c:421) > sock_sendmsg_nosec (net/socket.c:727) Reviewed-by: Emil Tsalapatis > > Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data") > Reported-by: Xiang Mei > Reviewed-by: Jiayuan Chen > Cc: Jiayuan Chen > Signed-off-by: Weiming Shi > --- > To sashiko: > > Regarding bpf_msg_push_data() reading "copy =3D msg->sg.data[i].length" w= ith > i =3D=3D msg->sg.end (appending at the very end of a full/near-full ring)= : > > This is pre-existing code, not touched by this series, and reproducing it= needs > a narrow combination -- a pure append at the end so the loop exits with > i =3D=3D msg->sg.end, a full/near-full ring, plus a prior push/pop histor= y that > leaves a stale length in the otherwise-unused end slot. A freshly built r= ing > zeroes that slot, so copy stays 0. We don't consider it practically repro= ducible. > > Even then it's already covered: the overflow check in patch 1 ("copy + le= n < > copy") rejects the dangerous case, and __GFP_ZERO in patch 3 prevents any= data > exposure. Not worth fixing here. > --- > net/core/filter.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/core/filter.c b/net/core/filter.c > index 3c8f1cedb217f..3e555f276ba80 100644 > --- a/net/core/filter.c > +++ b/net/core/filter.c > @@ -2872,7 +2872,7 @@ BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg,= u32, start, > =20 > psge->length =3D start - offset; > rsge.length -=3D psge->length; > - rsge.offset +=3D start; > + rsge.offset +=3D start - offset; > =20 > sk_msg_iter_var_next(i); > sg_unmark_end(psge);