From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr2-f1.google.com (mail-wr2-f1.google.com [74.125.225.65]) (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 5FD6D7E0FF for ; Thu, 13 Aug 2026 02:32:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786588350; cv=none; b=H/7Pyq+NbPETSvonJbj4l7ZkMKZAnG+gSCBWr4kRuCyEEJhKgrqmQS74sIQ6EVnqKOAvTbjBkCqWwvn3ShP0nnySu27o/FI9mVKTAmcGSPPlUiH7qqDtmX+EWsAXMJrDL8Pqjf79XNFWkblHpOW+C0ef1GBNNx/YHudZN/zSzwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786588350; c=relaxed/simple; bh=036Im8OT7vtFN+Z+XmJ1SUKckGDPPAoqQODBJMhZKl0=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=q8U5OfsRmzdd8NtWkHYrsvB81+MQFPTfMEdWzRTcKkoJ3iIP8Gve8oDU8J4O/rrR02AqCHMLZM4VnEQ/nS4pMJciw4v6vTitpLzt45Yzd+vXXJvgIaDhpIWbNxDusFVlhE9qqdEII1svg+0VqgysIxdhfO5J0NZK86dgly0sYtM= 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=RXYZVrav; arc=none smtp.client-ip=74.125.225.65 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="RXYZVrav" Received: by mail-wr2-f1.google.com with SMTP id ffacd0b85a97d-47fe3f552f0so81093f8f.0 for ; Wed, 12 Aug 2026 19:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786588346; x=1787193146; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=OO/kWqWey78xSCQX80s8SUkYWYReSxkVRzCtMWpZ454=; b=RXYZVravDJOPK/ZIqrp36IUhDHoBEIy/GHMAGPMggL8JiV9UTvTNbLVe7qVanhXMh8 FeI7DjDNceCnxIKcipDGBkuBCt5PHgnJGMo/sXSPGKqaAgIspEMS5tsh5jBz6K69QkMJ XUmCefVz+i8A6HwJgWyIMkVNBGxN9i6MsDrEMOKxRiBiFcZIaBDJ/TwFlDgFC2mrhg51 vQ15vvpffdqQv3g9p0Hf9g5VxnQUwzvEhmEi5udgQsZHwkH8K4WJnG1KJs2g3WXMjzdt 6UXrJGyEYFSWV/eATE8HNRPnfUc2U19kIIzSxbQdbjyrg5JiWakyY0dYTV4e/65JyThl Cblg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786588346; x=1787193146; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=OO/kWqWey78xSCQX80s8SUkYWYReSxkVRzCtMWpZ454=; b=qRAQlqko/ODtkgEdtOe05Q7qkHpIKPb1bRJHzY6SDRSD98Phj7crtdfjuz41fFRXMQ /phnywKw6og5QAVOQ4FXjxlUY/eyTwqWMLgLKCY78z4v1ru0HpbWfl00C8j4vgNMVdW3 1/YlAMtnsEpKMaIiKvU0oVapz9wchX9GsfbhLNYWiEYqTw86BoqoT7NoRYQXHAwIkg2R rzjWyKikD8FLTPOzWhRnuJl0fGkKofqWiwTeTGu4am5lm5Zd+TAhCazSOelieFgTodMy gEcYYYOLRhNL54i4lah6dR7Cmwb74+H/KrU6EfYLw7Oc4FHHRjWKbna3QNay+0Yx9ljS QSDQ== X-Forwarded-Encrypted: i=1; AHgh+RpxSKlL5q+QmCGG6jEF5Zw4bb0XsrgL5pcv8GR+JM7B27vtx6yLpvGTdMiS/eilTYXLLxRCP6tKAce5yk0=@vger.kernel.org X-Gm-Message-State: AOJu0YyWgjIAFdqWj/NRN+9bdtv+Yp03Z7LuNYCzl7+8n8wOhNgzYPj4 L1BCaM4Q9cSF6DDFn+mUkAJaiF2Z4MtBDPRIv+TcuLooB4mZQryMXFMb X-Gm-Gg: AR+sD11z3kkUJ1OXRsbIDZRAMgHZ5OrzUeN776UGRnPtTnzTm95ccSnsqotobIibGrG IFpc1o9l1hdS9aM/VaA17bCzA6gcVd0Sna83wehKKdf4KF7A9oLu7WWMlLZZ708U85DQJbzDWg4 GyE6vgNPGVW5t/w4eRpDDKzZQYziSVITutZS5t9dNrudlhFr1I+3GTtEX2kKhLXq79IaZVIwPYV Rq03OPEzMxE47Nv6rZ/ltvTJR55t0L+KTNdi+Hm8xDaS0iyLEI//8NqV5TgpIw+qeI0mlfXo9Wm jGRxlKNA7MhIT9oW4/HPbyqozwZrO0yabd1xrEkK+BAU+L06nac3RSjo1UmBHW9grDg4rlAuhUa Bho/cdgbrM5VyDRF1l5wC/XdrlSPWgYFCn4k0+EtODistmPQYVmWgTURYLtnkhabiKOFS10ePN+ HrtAotXzZCcY5sAzuTlAtoJPNBxeNvtYZQ+FJ4xn3DAZhvX7CITQyai0zOg+A+w91Ja2lGvFCLy 8CfrjzuGqs1RDqDGE1yBL1ho2Ubp3L24Bbp94H+9EJXadRoXNqqEUcuaSGGmFic0hIGDUfcoWNR Mwncddq6WoHZb+wfE7wF0WaL3xo= X-Received: by 2002:adf:fd4f:0:b0:481:474a:99f6 with SMTP id ffacd0b85a97d-4815a01c4e9mr2226008f8f.19.1786588345450; Wed, 12 Aug 2026 19:32:25 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815a569c2bsm2320892f8f.12.2026.08.12.19.32.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Aug 2026 19:32:25 -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, 13 Aug 2026 04:32:24 +0200 Message-Id: Cc: , , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Eduard Zingerman" , "Martin KaFai Lau" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "Emil Tsalapatis" , "Shuah Khan" , "Viktor Malik" , "Justin Suess" , "Kaitao Cheng" , "Leon Hwang" , "Yiyang Chen" , , Subject: Re: [PATCH bpf v3 4/4] selftests/bpf: Test untrusted allocated-object pointers From: "Kumar Kartikeya Dwivedi" To: "Ning Ding" , X-Mailer: aerc 0.21.0 References: <20260803112218.3361213-1-dingning04@gmail.com> <20260803112218.3361213-5-dingning04@gmail.com> In-Reply-To: <20260803112218.3361213-5-dingning04@gmail.com> On Mon Aug 3, 2026 at 1:22 PM CEST, Ning Ding wrote: > The verifier previously allowed pointers used after RCU protection ended > to reach bpf_refcount_acquire() and, for one object layout, a direct writ= e. > If the object was freed and reused, these operations could access stale > memory. > > Add tests that keep BPF_PROBE_MEM reads accepted but reject reference > acquisition and direct writes after RCU protection ends. Cover both teste= d > object layouts. > > Reported-by: sashiko-bot@kernel.org > Link: https://lore.kernel.org/r/20260726021304.97ED91F000E9@smtp.kernel.o= rg > Assisted-by: Codex:gpt-5 > Signed-off-by: Ning Ding > --- > .../selftests/bpf/progs/refcounted_kptr.c | 100 ++++++++++++++++++ > .../bpf/progs/refcounted_kptr_fail.c | 27 +++++ > 2 files changed, 127 insertions(+) > > diff --git a/tools/testing/selftests/bpf/progs/refcounted_kptr.c b/tools/= testing/selftests/bpf/progs/refcounted_kptr.c > index fd35093285c0d..b70be8b52ff80 100644 > --- a/tools/testing/selftests/bpf/progs/refcounted_kptr.c > +++ b/tools/testing/selftests/bpf/progs/refcounted_kptr.c > @@ -893,6 +893,106 @@ long refcount_acquire_rcu_map_kptr_null_checked(voi= d *ctx) > return 0; > } > > +SEC("?tc") > +__success > +long map_kptr_read_after_rcu_unlock(void *ctx) > +{ > + struct map_value_refcount_only *mapval; > + struct node_refcount_only *n; > + int idx =3D 0; > + > + mapval =3D bpf_map_lookup_elem(&stashed_refcount_only, &idx); > + if (!mapval) > + return 0; > + > + bpf_rcu_read_lock(); > + n =3D mapval->node; > + if (!n) { > + bpf_rcu_read_unlock(); > + return 0; > + } > + bpf_rcu_read_unlock(); > + > + return n->key; Here, n->key won't read untrusted pointer, since tc progs have RCU protecti= on, so I don't think the pointer becomes untrusted. > +} > + > +SEC("?tc") > +__failure __msg("is neither owning or non-owning ref") > +long refcount_acquire_graph_after_rcu_unlock(void *ctx) > +{ > + struct map_value *mapval; > + struct node_data *n, *m; > + int idx =3D 0; > + > + mapval =3D bpf_map_lookup_elem(&stashed_nodes, &idx); > + if (!mapval) > + return 0; > + > + bpf_rcu_read_lock(); > + n =3D mapval->node; > + if (!n) { > + bpf_rcu_read_unlock(); > + return 0; > + } > + bpf_rcu_read_unlock(); > + > + m =3D bpf_refcount_acquire(n); > + if (m) > + bpf_obj_drop(m); > + > + return 0; > +} I don't think you ran these tests, they have unexpected success, mostly bec= ause tc has RCU read protection already, so n passed to refcount acquire is not untrusted. > + > +SEC("?tc") > +__failure __msg("only read is supported") > +long graph_map_kptr_write_after_rcu_unlock(void *ctx) > +{ > + struct map_value *mapval; > + struct node_data *n; > + int idx =3D 0; > + > + mapval =3D bpf_map_lookup_elem(&stashed_nodes, &idx); > + if (!mapval) > + return 1; > + > + bpf_rcu_read_lock(); > + n =3D mapval->node; > + if (!n) { > + bpf_rcu_read_unlock(); > + return 2; > + } > + bpf_rcu_read_unlock(); > + > + n->key =3D 1; > + return 0; > +} > + Same for write here, it succeeds... > +SEC("?tc") > +__success > +long graph_map_kptr_read_after_spin_unlock(void *ctx) > +{ > + struct map_value *mapval; > + struct node_data *n; > + int idx =3D 0; > + > + mapval =3D bpf_map_lookup_elem(&stashed_nodes, &idx); > + if (!mapval) > + return 0; > + > + bpf_rcu_read_lock(); > + n =3D mapval->node; > + if (!n) { > + bpf_rcu_read_unlock(); > + return 0; > + } > + bpf_rcu_read_unlock(); > + > + bpf_spin_lock(&lock); > + bpf_spin_unlock(&lock); > + > + return n->key; > +} > + Similar case. > static long __stash_map_empty_xchg(struct node_data *n, int idx) > { > struct map_value *mapval =3D bpf_map_lookup_elem(&stashed_nodes, &idx); > diff --git a/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c b/t= ools/testing/selftests/bpf/progs/refcounted_kptr_fail.c > index acd3e81a39168..3408f68ad444d 100644 > --- a/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c > +++ b/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c > @@ -127,6 +127,33 @@ long refcount_acquire_rcu_map_kptr_unchecked_drop(vo= id *ctx) > return 0; > } > > +SEC("?tc") > +__failure __msg("is neither owning or non-owning ref") > +long refcount_acquire_after_rcu_unlock(void *ctx) > +{ > + struct map_value_refcount_only *mapval; > + struct node_refcount_only *n, *m; > + int idx =3D 0; > + > + mapval =3D bpf_map_lookup_elem(&stashed_refcount_only, &idx); > + if (!mapval) > + return 1; > + > + bpf_rcu_read_lock(); > + n =3D mapval->node; > + if (!n) { > + bpf_rcu_read_unlock(); > + return 2; > + } > + bpf_rcu_read_unlock(); > + > + m =3D bpf_refcount_acquire(n); > + if (m) > + bpf_obj_drop(m); > + > + return 0; > +} This also passes. > + > SEC("?tc") > __failure __msg("Unreleased reference id=3D3 alloc_insn=3D{{[0-9]+}}") > long rbtree_refcounted_node_ref_escapes_owning_input(void *ctx) Please respin and only send patches after you have tested them properly. The right fix might be to use fentry.s for these tests to trigger untrusted marking of pointers. The fixes themselves do make sense. For the next version, target bpf-next and drop Cc: stable. pw-bot: cr