From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f52.google.com (mail-dl1-f52.google.com [74.125.82.52]) (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 DF90D2ECEBB for ; Mon, 19 Jan 2026 20:24:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768854259; cv=none; b=CRpAk8TnCGWMDY1kFcqdSYomAxhaKa08hL4vFLUsKCDuR8gGl283bgL0BcczdBaQhpAwLizKLNjEhlYkJ4HaZu2izBnAj4uMzpYvueRvw4TPs4zLBjevpmnA3QsACgHFgf3Vsdm7oOnH+9SKPBoRfat+NI7oJlNqmk3a24zEbE0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768854259; c=relaxed/simple; bh=H2bq/OAD2o59J4yItaZmIuW7yJ0igTT8/wThWqgVO0I=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=OUfsOQp9SFfiWmHTD3MK2rZXm4pqF9z1bqg6ytJTkR5P3YD0A7Fw6Qx9t54tqZL7B3rNy/TE01wx1x2mnNEghrnQkwbJ3ohrPlWmxCpaViLcNRcC4eaPfctw6CxwhrZFEzlXHC4hRItveUNoWTgJg7R74N2UjdUlUHmLRQvTF1U= 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=J9VJpI0I; arc=none smtp.client-ip=74.125.82.52 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="J9VJpI0I" Received: by mail-dl1-f52.google.com with SMTP id a92af1059eb24-12336c0a8b6so9959657c88.1 for ; Mon, 19 Jan 2026 12:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768854256; x=1769459056; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=AbY+jX2Rjs0OZqwqKdZgEOaZOTOcp8GauBAWp66xGL0=; b=J9VJpI0IU0f5V9OfudFRrZrd+7j91wUI/bCCg4jCP1R/Ll0yoErbe/ApMYASUj06v+ zxLdFHqtr3UK3v0muw73wNpd+6oQPeCTIDfQ7daKC261uIigg+TQ6WYMalmF4lwykaVz sO8K+/ISXhWQJvV0m3Q844TIpp53CxH+HL46sUUjS37OAiHXFZF34U2PVMBzk80gaM2d Ip3qkQsDi8I6x8PnsznxNEsFtidF5ikaOBAoI5sfhcbnRULWRgj0d6Gz8AGJLyJDW/Gv WCaNv5IVug7ZLoDFj0zDz5NvrItsV/jtmBPGyoys9mBSbX/DSWKHmF1oxfih7OkeoyKd 1SzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768854256; x=1769459056; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AbY+jX2Rjs0OZqwqKdZgEOaZOTOcp8GauBAWp66xGL0=; b=A0wXHlOaMXZ/HtjiKLBSZf/mXNulls4Y0nBCV43/VxeAlupMaYbuliDBCVDciXxDAF lu5F8lrLET9H21vTdBVJaSqB83cc5XIrGvp0MD2/aEPGF6hYtgvYiJNpr8mC8nEsJj5r Po86Cxj9KF4S+AN//ZPZ/VMyyp1k17wKe7q6l73qwr/xAoSHp/7E7DwOoLH7aZ2P4tA7 KaX3/CDWCsss6QKcyfGVmFSwtabM58gaQSc1k+kHYV3Alpo/sRL2/aNLGpHFDUrLgead HBCsRwTU+8k16Pb+yMinAUwbsuegiLz4yg3k3IhKubGUIy0RPDwlHq7Tl1lsUdgox5YP rK6Q== X-Forwarded-Encrypted: i=1; AJvYcCUtJOdwoxxuyBdgJczRgi0Hc+voVs9QUDabt8+68HBkvdDM20M/LgyKkSr43y744U3YfHItZRFjL76UrK8=@vger.kernel.org X-Gm-Message-State: AOJu0Ywj/rYzrZBtFFS0ZciFGM9sc07+z30H/jB5uV+C8DV9bK57hN/a jQ7/usW34IiH2WUbtkN/hLxfUnVW0yeQB83YiIOwumQE6fsk9hCNOxcc X-Gm-Gg: AZuq6aIQlTMTD51y+OeObOaTWYn/GhXxYIBnY80uHiAH6Yl3Ko63/E5iEyqovJeMdb6 Hx1Hy8pjrGA6haqFz40ZuJ3WsD0rpPrJ6UFuUchPy68oxrBYM/FsYVzWdTLugi7pJViLvi9cH+w bS4RJKAJf+zmNiFQldYSo8Fa8wRuB+1ts/gt/57QdMPzErhIAeXVj4Zm1eVMWtPPoOALE093SL/ ZSUsVksiBggU7p5VQzNPuTlfUOlR9dYFCIbSyVbDB7PIUMnnR0FQGtV38Q1n0epW4Z+l83n7q30 ruDX4GLFUM+OluO020SEihpEM1YgaVulH7Ig9IvP3uMxSdHoTTugZsCZtHTfkWNbEfSVoqjXwjK YpXp+bZuxfkh75Xkkknr+w7mQqHFNUUr1L7U0NMVKcdzvWRedbFSHg3fR2CSKQZQP+TXsslagd9 jm1d0Nem+O/YpnalQ+TOaDdbzA7bMOt6yHQA+TmEkQepHF8Mcazrplskcfd5JWxUSnWQ== X-Received: by 2002:a05:7300:3214:b0:2b4:6b84:b7d7 with SMTP id 5a478bee46e88-2b6b3f14121mr7909753eec.8.1768854255620; Mon, 19 Jan 2026 12:24:15 -0800 (PST) Received: from ?IPv6:2a03:83e0:115c:1:4cd6:17bf:3333:255f? ([2620:10d:c090:500::aa81]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b6c56a23ecsm12145563eec.11.2026.01.19.12.24.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 12:24:15 -0800 (PST) Message-ID: <55f01664fc714615206cc8d100cabf4f310f2302.camel@gmail.com> Subject: Re: [PATCH bpf RESEND v2 1/2] bpf: Fix memory access flags in helper prototypes From: Eduard Zingerman To: Zesen Liu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Matt Bobrowski , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Daniel Xu Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, netdev@vger.kernel.org, Shuran Liu , Peili Gao , Haoran Ni Date: Mon, 19 Jan 2026 12:24:11 -0800 In-Reply-To: <20260118-helper_proto-v2-1-ab3a1337e755@gmail.com> References: <20260118-helper_proto-v2-0-ab3a1337e755@gmail.com> <20260118-helper_proto-v2-1-ab3a1337e755@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Sun, 2026-01-18 at 16:16 +0800, Zesen Liu wrote: > After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tr= acking"), > the verifier started relying on the access type flags in helper > function prototypes to perform memory access optimizations. > > Currently, several helper functions utilizing ARG_PTR_TO_MEM lack the > corresponding MEM_RDONLY or MEM_WRITE flags. This omission causes the > verifier to incorrectly assume that the buffer contents are unchanged > across the helper call. Consequently, the verifier may optimize away > subsequent reads based on this wrong assumption, leading to correctness > issues. > > For bpf_get_stack_proto_raw_tp, the original MEM_RDONLY was incorrect > since the helper writes to the buffer. Change it to ARG_PTR_TO_UNINIT_MEM > which correctly indicates write access to potentially uninitialized memor= y. > > Similar issues were recently addressed for specific helpers in commit > ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffe= r") > and commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name= args"). > > Fix these prototypes by adding the correct memory access flags. > > Fixes: 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking= ") > Co-developed-by: Shuran Liu > Signed-off-by: Shuran Liu > Co-developed-by: Peili Gao > Signed-off-by: Peili Gao > Co-developed-by: Haoran Ni > Signed-off-by: Haoran Ni > Signed-off-by: Zesen Liu > --- I looked trough the helpers annotated with MEM_WRITE in this patch, indeed the write annotation is missing from these helpers. In conjunction with the following logic in verifier.c:check_func_arg: case ARG_PTR_TO_MEM: /* The access to this pointer is only checked when we hit t= he * next is_mem_size argument below. */ meta->raw_mode =3D arg_type & MEM_UNINIT; if (arg_type & MEM_FIXED_SIZE) { err =3D check_helper_mem_access(env, regno, fn->arg= _size[arg], arg_type & MEM_WRITE = ? BPF_WRITE : BPF_READ, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ // arguments considered read-only by default false, meta); if (err) return err; if (arg_type & MEM_ALIGNED) err =3D check_ptr_alignment(env, reg, 0, fn= ->arg_size[arg], true); } break; This patch fixes a real problem. [...] > index fe28d86f7c35..59c2394981c7 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c [...] > @@ -1526,7 +1526,7 @@ static const struct bpf_func_proto bpf_read_branch_= records_proto =3D { > .gpl_only =3D true, > .ret_type =3D RET_INTEGER, > .arg1_type =3D ARG_PTR_TO_CTX, > - .arg2_type =3D ARG_PTR_TO_MEM_OR_NULL, > + .arg2_type =3D ARG_PTR_TO_MEM_OR_NULL | MEM_WRITE, > .arg3_type =3D ARG_CONST_SIZE_OR_ZERO, > .arg4_type =3D ARG_ANYTHING, > }; > @@ -1661,7 +1661,7 @@ static const struct bpf_func_proto bpf_get_stack_pr= oto_raw_tp =3D { > .gpl_only =3D true, > .ret_type =3D RET_INTEGER, > .arg1_type =3D ARG_PTR_TO_CTX, > - .arg2_type =3D ARG_PTR_TO_MEM | MEM_RDONLY, > + .arg2_type =3D ARG_PTR_TO_UNINIT_MEM, Q: why ARG_PTR_TO_UNINIT_MEM here, but not for a previous function and not for snprintf variants? > .arg3_type =3D ARG_CONST_SIZE_OR_ZERO, > .arg4_type =3D ARG_ANYTHING, > }; [...]