From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f170.google.com (mail-dy1-f170.google.com [74.125.82.170]) (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 0298C4963DF for ; Tue, 9 Jun 2026 18:21:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781029315; cv=none; b=tDRMpeeiQixYJ0sCH++V3zORuFKKOGFBeQRkCNlB+FpxQnUKTjWyUl3qLcuP6F4VZb4Dbw03gFuN9x2i+hBj/47rDFkYO9OWD4rUU+eo48qaP7ENT60K16Kysp+IimVq0l593INye2HIRuennPgSDNBC3+9jPLeyEPwl6sXsuGI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781029315; c=relaxed/simple; bh=Pj5qSOkBbQLxrzD3/c2ksrSEnkBsZlcOQdL+gxq6HnM=; h=Mime-Version:Content-Type:Date:Message-Id:To:Cc:Subject:From: References:In-Reply-To; b=Q9vDIWgi8KclQJayFWdLapX6D9H5+X1GgOMavK0s9Y1j/dNux6EBWFSTHKOF/lgoUiBUQ8gZl3sn1hi7SJvIzs05QAfKSdg5FY1uiKpzwz21zXtlybAeyYL9TarsjQWkeMMdbDDF2IC+s/j3OLjaclmRHFPRYKpZj0WDKvP6hzY= 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=vS/YJGpq; arc=none smtp.client-ip=74.125.82.170 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="vS/YJGpq" Received: by mail-dy1-f170.google.com with SMTP id 5a478bee46e88-307d0405e07so1545446eec.1 for ; Tue, 09 Jun 2026 11:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsalapatis-com.20251104.gappssmtp.com; s=20251104; t=1781029312; x=1781634112; darn=vger.kernel.org; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sI7a7X7zVj9lSZe9s9onuQtmD1DDrDFRkHXe/vB2iho=; b=vS/YJGpqy0GyKoGzzrEQSApPikWTgr1VUpOjFyZ331FNTWQ0z6ce1FtOxeVVz0Bj0z XJsgmpFbYcGGZOSFFg5TjKtigd3vNM2wfaJ3HDr4INpK2hYZqZBZ2nl+N40MDiIXpVGk 7WgIfp0RvYWWoRFj1Ii5NabkwCj7njQd3OO7/p+wiB1KoqxRBlA3PHShfzjYWUnclqHV we1E5Bt0MJg1mKemTdGz/VHxl8kQ9f9aJTMLPJ+KmHehU5j4ykXv7hdXtgroojHxy59o D8aev+zNWUSSW3Gcc6QE49SJ5erft0gwKfX1jmlEHB66qajP8sH3+1ZotiBJksJK+iyL AJhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781029312; x=1781634112; h=in-reply-to:references:from:subject:cc:to: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=sI7a7X7zVj9lSZe9s9onuQtmD1DDrDFRkHXe/vB2iho=; b=QzhsFTQ2J0fkGXTjNAHrSWqeBmfggCDHVCQ66oxvmFacbzpxN0JxQSQQUU2B4LYWWt 4c/W6Wp0+94aSTwnr4I1ijMAxedle4VGstJvdDdslHvhJ1ck1DaXNXvYOEkn/c5du+uE WmCCcMlF5+dYs8LXM8/6CNtuIB7m5QyCGPLUr2+spj39SkOoKv6k17yhtRNe78XRtAUd 7T12QB1IHef4dFA1ewsEjHmTTuuoqgy5FyQklagZNCh6/adWwSOaLc1G+I43UYAiAuaM RIqi1mQojF6xk1jGsdVDCQ9BBzdIPVTIra9PvRCqskK/rt8GFt5YUCYP6pDcfMJ/Ozvi bUrg== X-Forwarded-Encrypted: i=1; AFNElJ/N6vW4y5rEC8MZC5GURK535ZvU93nJJjULFRlTWJnwkZawovlvRqGuLirmSoH/fI4Oh8qhagX6H/bxhoU=@vger.kernel.org X-Gm-Message-State: AOJu0YyogogiLEo6JW6C8//DrY/gzrmVjqfIWxGrdwNGm3+P5Xrk7YZm ozXz4Jr9XyNvs5j4hhoMCaHGYPI4VOKqkYvccRvgH1+ZRcntVez3wwHhRdwUKuaaZZc= X-Gm-Gg: Acq92OFCOyHLVdRMNsZ627lsWZfhW33+R90qkAhAU+Kjqkcudg5YXDvKmR8kM8QdVKc o1+yGd1KaQHtZT/ejkjloR2m5RxybG/kNKvcxbu9k/19NN5QNpCaVlMZVKxdZ1wbQkvebcjUW6y ACUS0PwVFXK9Srs0Hh7x8R9JzA6iHr+NG0CXd9Clmg4cnGor1uYfFS/0JuGlHoeDLGYRq52fCyf PmgiwkG1D5U+f3FXPiJNpWIaoZU1wFJ3y2Sj1RWv8DcsHXN8D3Kes+704gvXz1t8XF7UW2MeBW1 SYIfMEw2Ud9z079Yg5GHb5GNzoSOH46tao4nDDdV2qLmLsUe0W1BcYKH7RKL4rMID9RbXzrfHi6 aPvCEgZz/KJPFzV2cc8SjgTt06Ce8u3FWMfBqxs/GFVmfRZ1QDzYXyREVSbLYQqSSt2Yq7qDu7M GP/WSlC0LA+teLoaKiP+n5x4Zf9g== X-Received: by 2002:a05:7300:2321:b0:307:393a:8f1d with SMTP id 5a478bee46e88-3077b0a4d7emr13442792eec.14.1781029311901; Tue, 09 Jun 2026 11:21:51 -0700 (PDT) Received: from localhost ([2620:10d:c090:600::3297]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3074df102a1sm20976948eec.20.2026.06.09.11.21.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2026 11:21:51 -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: Tue, 09 Jun 2026 14:21:49 -0400 Message-Id: To: "Eduard Zingerman" , "Nuoqi Gui" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" Cc: "Kumar Kartikeya Dwivedi" , "John Fastabend" , "Martin KaFai Lau" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "Shuah Khan" , , , Subject: Re: [PATCH bpf-next 1/2] bpf: Reject scalar addition from untrusted memory From: "Emil Tsalapatis" X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260609-f01-03-scalar-add-bpf-next-v1-0-e6212e274155@mails.tsinghua.edu.cn> <20260609-f01-03-scalar-add-bpf-next-v1-1-e6212e274155@mails.tsinghua.edu.cn> In-Reply-To: On Tue Jun 9, 2026 at 1:01 PM EDT, Eduard Zingerman wrote: > On Tue, 2026-06-09 at 22:55 +0800, Nuoqi Gui wrote: >> scalar +=3D rdonly_untrusted_mem reaches adjust_ptr_min_max_vals() with = the >> pointer as the source register. The untrusted PTR_TO_MEM case returns th= ere >> without updating the scalar destination, leaving stale verifier state. >>=20 >> Reject that addition before the early return. Pointer +=3D scalar remain= s >> handled by the existing untrusted-memory rule. >>=20 >> Fixes: f2362a57aeff ("bpf: allow void* cast using bpf_rdonly_cast()") >> Signed-off-by: Nuoqi Gui >> --- >> kernel/bpf/verifier.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >>=20 >> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c >> index c8d980fdd709..c6b350f9585a 100644 >> --- a/kernel/bpf/verifier.c >> +++ b/kernel/bpf/verifier.c >> @@ -14823,6 +14823,14 @@ static int adjust_reg_min_max_vals(struct bpf_v= erifier_env *env, >> * This is legal, but we have to reverse our >> * src/dest handling in computing the range >> */ >> + if (opcode =3D=3D BPF_ADD && >> + base_type(src_reg->type) =3D=3D PTR_TO_MEM && >> + (src_reg->type & PTR_UNTRUSTED)) { >> + verbose(env, "R%d tried to add from %s to scalar\n", >> + insn->dst_reg, >> + reg_type_str(env, src_reg->type)); >> + return -EACCES; >> + } >> err =3D mark_chain_precision(env, insn->dst_reg); >> if (err) >> return err; > > Should the fix be like this: > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 7d27ba396d32..9c85dd680a46 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -13593,8 +13593,10 @@ static int adjust_ptr_min_max_vals(struct bpf_= verifier_env *env, > * Accesses to untrusted PTR_TO_MEM are done through probe > * instructions, hence no need to track offsets. > */ > - if (base_type(ptr_reg->type) =3D=3D PTR_TO_MEM && (ptr_reg->typ= e & PTR_UNTRUSTED)) > + if (base_type(ptr_reg->type) =3D=3D PTR_TO_MEM && (ptr_reg->typ= e & PTR_UNTRUSTED)) { > + *dst_reg =3D *ptr_reg; > return 0; > + } > =20 > switch (base_type(ptr_reg->type)) { > case PTR_TO_CTX: > > Instead? Seconded, AFAICT there is no reason to fail verification since we just the pointer's value to the scalar. Whether the operation makes sense is up to the programmer to decide.