From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) (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 6600C247291 for ; Wed, 22 Jul 2026 00:12:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784679139; cv=none; b=uqzfA8/78cfKMDLs2ImV5xRb3mNp9hswP8yok4LdHchjBDY4kVeNLXDOy9Fdth+WKI9uLifCePKSXwvq4WyPwlPBBV4q2Vy0EHo1cjmo6MejTrxjFhgziMbgQHOzq7Kndc7KflTCg9yhK0YKUNQSxKfFE+Z1wYHOcaQfobcZDDc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784679139; c=relaxed/simple; bh=INJwYTrSQ3WAovcuijCA3YELaIRjXjzM8P0z1g5h5Ag=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=g5IuWkuOUNcEmDAsY81y02iR6kQwvnBXWGbCY58GNsJe4exOTYQp1RKqMbdv+0CNijwZ4dFw4q5QXYdbTW0wari1yu2JQ6cIQE2vzGuhB7QV5jqK099fuwoEDKhn/qmSeH+m6xwUXB8b0ChyESXJVUrUPC1Yfzafo9KU5Xzq4Q0= 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=ToV//2k3; arc=none smtp.client-ip=209.85.215.175 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="ToV//2k3" Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-c9b373d5af0so9036615a12.2 for ; Tue, 21 Jul 2026 17:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784679137; x=1785283937; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=cWKpfdDZ5rwahGdKmtliUWjX0cNTR5TraqAEREqnMtI=; b=ToV//2k3xpy9GDnRpv5mpAzagZ8Y9EAsbyNTwifQW1bDq2xHUmURlHh/ebdqo1AVQE N/KDBsEYSiuCFOqVfwhuQO529qBgnZgPsB4hKovZg0ZPkrfe8iJYXddQSnCTsPYFtqA2 WJGrKHH8CDrUYV3vnVEqyaFtFA+FEoPX7y3jWC5NddglaiNwNrxNPX6DqTZnb//HeI9Y CJahrxx/o6A97hKnUC6q3rEMkc221q2BuswM5HzVaYu9nXMlhe1B2eTztJFy7wiI4x5y FFBkflxifoty2gZLQot5UGdIC9K9tvUpkWvcqbji3yCr23NKGCF6q7+jj+4G3ZPIkIlG ByTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784679137; x=1785283937; h=mime-version:user-agent:content-transfer-encoding:content-type :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 :content-type; bh=cWKpfdDZ5rwahGdKmtliUWjX0cNTR5TraqAEREqnMtI=; b=fce2fvlMoRZ+5PFLmfCCGNkukh5QTbqQG0AMtjZZ7lavhdv9UoLWiKC37ZlGJoDuGc U1n9FLBzHH2DbZg/uBZvn8LjruUuAejwDRmVb77L1Y+7gH46oEnU7rLbTHJh0qJcCLzc lFumEY2pNtENn5wuDFT6Gr0bNwGjn896QJjBktf+zS3gKvstVzkEGSNzdi8hJW5vNWnZ DeS4DnmAtRuSHyO6nmBVVbVOKIca8jmiYiuamIvToYk0a+XALzxBGyjZJzepS2RsgqG5 VmZ5q8HWvF5vitiLMdDehuKF7TXKqkE63UWNs9PZbSwjjdaLs+zOrUCRKpGnU28+O+2Q wsmQ== X-Forwarded-Encrypted: i=1; AHgh+RrAublcZnvk5ua1F0X77r5f5nD0b5IrMu5r9wA7/kidMOX7OoXf7Ajq1mqLkRGhh14Ng5EtRBvhUV3Ef58=@vger.kernel.org X-Gm-Message-State: AOJu0YxGvPQhBKLHpau8i+lkE0Kp72dRFBGOHOiC3zc1ldZPQhfA9L9M Be02iOOGzlowUs3oHr+TbuL7sGfMzyQynNp3P8DURq1Btg8/gFmuRYKT X-Gm-Gg: AR+sD13VI0lETfjHnXEMEjd3c2pO/nm0O+lXdhwveMfGVehfXI2RXlSkKzthUOgVGgH 4euUoABowKoV9TDWNc1Fiu+mLX7nVeh6+/NFvRb1uRnmyinBxqvJo2Qbb3uF7BscNkSi0N+1QMs UbGJeo7qQyAfwDRMg2LCy/M2zrLh5w1dK50Gff6Tq5kD1GN/BUXAfXNjPOKT33lkhbvBiwyiEzk t4sp3ZITZosVN3niSWRpeiNKoRS3bzos8ttycm7sitR05pdps3h45bIeOfACwo1eKsWxLbdbtQc dgDrkzMLnElImln3x56hZSyc+kEjdCirSIOUYtrmYQzK1qshaOE6eRHWkWk38haOp1WP0coeKO4 2Fug5ETPsz2f3Yv/MWyw2cp58nBOZQS7DtG2vLG31J7xTvXstPUs89QJQDm47qFRlUsyy4vtd11 LTd6ULVuA7lPNqfjb81uStyheLnWGq7CWq0EAJf5ZYXx8I1EFKt90O2Zzp X-Received: by 2002:a05:6a20:734d:b0:3c3:69d0:c573 with SMTP id adf61e73a8af0-3c3adaae79amr21522093637.68.1784679137427; Tue, 21 Jul 2026 17:12:17 -0700 (PDT) Received: from ?IPv6:2a03:83e0:115c:1:cda2:e912:7f2e:f787? ([2620:10d:c090:500::7827]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3147df06864sm2786421eec.15.2026.07.21.17.12.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2026 17:12:16 -0700 (PDT) Message-ID: <976ae2fbf6f2ead76622e39813bfda6a6981d382.camel@gmail.com> Subject: Re: [PATCH 1/2] bpf: Preserve stack frame number for commuted arithmetic From: Eduard Zingerman To: Yiyang Chen , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi Cc: John Fastabend , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Shuah Khan , Emil Tsalapatis , bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 21 Jul 2026 17:12:14 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (3.60.1-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-07-21 at 09:39 +0000, Yiyang Chen wrote: > When scalar +=3D pointer is handled in adjust_ptr_min_max_vals(), the > destination register has to inherit the pointer register state from the > source pointer. Copying only selected fields is fragile because pointer > provenance is tracked by several bpf_reg_state fields. >=20 > For the commuted form, pass a temporary scalar offset register to the > common pointer arithmetic helper and copy the full pointer state before > applying pointer arithmetic. This preserves the frame number for > PTR_TO_STACK registers and keeps parent identity fields consistent. >=20 > Fixes: f1174f77b50c ("bpf/verifier: rework value tracking") > Signed-off-by: Yiyang Chen > --- > kernel/bpf/verifier.c | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) >=20 > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 52be0a118cce0..3c0af83db4672 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -13796,11 +13796,12 @@ static int adjust_ptr_min_max_vals(struct bpf_v= erifier_env *env, > return -EACCES; > } > =20 > - /* In case of 'scalar +=3D pointer', dst_reg inherits pointer type and = id. > - * The id may be overwritten later if we create a new variable offset. > + /* For 'scalar +=3D pointer', dst_reg inherits the complete pointer > + * register state. Individual fields may be adjusted later by pointer > + * arithmetic. > */ > - dst_reg->type =3D ptr_reg->type; > - dst_reg->id =3D ptr_reg->id; > + if (ptr_reg !=3D dst_reg) > + *dst_reg =3D *ptr_reg; Lot's of tests are failing on the CI, please investigate. > =20 > if (!check_reg_sane_offset_scalar(env, off_reg, ptr_reg->type) || > !check_reg_sane_offset_ptr(env, ptr_reg, ptr_reg->type)) > @@ -14854,15 +14855,18 @@ static int adjust_reg_min_max_vals(struct bpf_v= erifier_env *env, > bpf_alu_string[opcode >> 4]); > return -EACCES; > } else { > + struct bpf_reg_state off_reg; > + We store such temporaries in the bpf_verifier_env to avoid excessive stack consumption. > /* scalar +=3D pointer > * This is legal, but we have to reverse our > * src/dest handling in computing the range > */ > + off_reg =3D *dst_reg; > err =3D mark_chain_precision(env, insn->dst_reg); > if (err) > return err; > return adjust_ptr_min_max_vals(env, insn, > - src_reg, dst_reg); > + src_reg, &off_reg); > } > } else if (ptr_reg) { > /* pointer +=3D scalar */ >=20 > base-commit: 0bcca2a42cc50b7d64a95c08dffc6b93661a7ea2