From nobody Mon Jun 8 04:19:59 2026 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 0AE622BE057 for ; Sun, 7 Jun 2026 17:10:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780852219; cv=none; b=Ek1pwWPTYGlzemZyW12WmvKWo4qr8SGcHJMWvKZeywBVAVsAQKnsFUgSSidW8pLVYZoxQuh8sh1gQzQRCadAvkx0jyqd4S+UHE6a6RWLjlELg/zOqozaNbFzdjYeIN8haOWJR+WS8qM6j4wDgaV2gfIQns8+kSagn1a9VFCQCoQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780852219; c=relaxed/simple; bh=Wj6INcB2ZWn71vsSX+uGeQfK2gKV41AKUbGx7CRisFg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ie1vclPGLNSocXIJRjzi7j2HqtEo70mJ6Q+6MvYyhINqskOvgrOGZfVXTgHj3XEsonWlF2OotQxMPdvgy8dDDBfnYhRakvRSSaL1xPDQkuv8TQxAwZ145jbxh1uaT0IbkKtg9Jah9GxcnZrn9nCYX1nTvF2xwzkyR31W8lSMCvQ= 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=hjmLcIhQ; arc=none smtp.client-ip=209.85.214.171 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="hjmLcIhQ" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2c0c3184c71so26286135ad.1 for ; Sun, 07 Jun 2026 10:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780852217; x=1781457017; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=OPsuDEC4emnE4igPvpmuWKON1k829WThn64znvg3mx8=; b=hjmLcIhQEYPmillRFf3WucOCrckndMbn9ijwD4YnlaMuuBWzHgV1i0kDpjLNX55YOm UXPdABmNb6vunD9ZOGmX4xZwaX4oU8hGBJSz0Pi4xSct5kEEdLrQBC8qqi+tOQ9sFAbA yu/DIh/FJDtat43b7Wz9zAvLg075cuD2Evwiht84mTGxO9oWfkMOPP4mQTU2oh/5imcg FRIpKIbubsEXdhcrUYQHf0FbmCqB+1XwyRm9N41dE3jQcz66dVLkKejc0tbHoXZUmzDG 6lyiZDwgBMiZaE348OsoeZ+ktaPvntrRPnR6s1ZPnmotMQhmR41bLcA+zAcGZbxhtlZp oB2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780852217; x=1781457017; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=OPsuDEC4emnE4igPvpmuWKON1k829WThn64znvg3mx8=; b=AFEHjPvTMHr6eCSp2QNxtVhBqBjCHnOA9ct/jCz2CV/0e9uIZwaqzDfE5Woi1p1K9n H3BriJyQdxmqTySOvXGgFf8d9wArPvOYDFzlTHMGzA1EpoiIkpY5/1L/bkDGyFoV6eKn 37kIUIKO223ETBllt8C0IHpRnkYNdGxq95pggKQ/Rk6NvYu2kpnbI9hKcHWgVXo+q8JR tIm0PZFeI43OoUFRdwhtpObXpaANQUk4pKrdYxlPumG0VcemLqN3D92R94poxrcwwx1c 2Hfm2Y7TdhIBnt036aH5UvhPlv1bM2WjKtb2ACfn4M4hhHiVGhM71cQOBulOuAVyk7zE QpEA== X-Forwarded-Encrypted: i=1; AFNElJ8Ue4aP2xpnaSpxhOiQf4rbIAWwLez7dd/Ss4di3QLszT6hSygVB8cBIs9qi00zDQSitQ+0EIxgOn7ISdo=@vger.kernel.org X-Gm-Message-State: AOJu0Ywmh7Vp904o1eHBPkm3hXI0HICvavtEYkYvKUHv6lvVge4p1KbQ 3hdvmvJJefbKFKIAEr/1QDCGgzvrdRXtzfU9H6c3zPSJ47iyYsTUgWUN X-Gm-Gg: Acq92OEEbwO+bvEhUhNYAdGeejdG3kKvy1kax3friOMLGoef8twP/r/ZcgCYpBfKPdD RIY5qkOJRM+BaJ8wxqaVWPm6ynRczB6pVijmHihwGXDx1YENolZWQdrIyCif+glqV7t/1bhHDDg nq5vH2ICyKycNxpIulZA0F0F5TSkL1raxFglIufX49E/JuYctUg+OA9gAY6dyfY6y9pHZZQ0o1p b5DMdc0pfAf6oZm6os38AqP36CqWIZ/B+pvwEQAhYdCTiFxiHisoRHOrtW6iCmGdKg+TlyV03mu Lta0rE0HXbqCv6YecQzukUvXN7yQhpwO1txpwusSqdwZoVu/u1paTMUGvWumwCsiFVzLRLY6W/d V2EOoJOEWH0TBUYBPwqxb/sRwjXRJ/ZCFVinT+XwRQ0u708SXYBj7mX/WKjG+EnFnTXFE5gBtEG IHicoFtZatiJzIGoSE40rgW2cHm/VL6KUSuBtlRDt/NA== X-Received: by 2002:a17:903:28e:b0:2c2:5446:30e8 with SMTP id d9443c01a7336-2c254463524mr29394155ad.18.1780852217123; Sun, 07 Jun 2026 10:10:17 -0700 (PDT) Received: from DESKTOP-MUHC17F.lan ([188.253.121.145]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c164f9ed6csm155375265ad.31.2026.06.07.10.10.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jun 2026 10:10:16 -0700 (PDT) From: Zhenzhong Wu To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, menglong8.dong@gmail.com, eddyz87@gmail.com, shung-hsi.yu@suse.com, stable@vger.kernel.org, mykolal@fb.com, tamird@kernel.org Subject: [PATCH stable 6.6.y v2 1/3] bpf: drop knowledge-losing __reg_combine_{32,64}_into_{64,32} logic Date: Mon, 8 Jun 2026 01:09:56 +0800 Message-ID: <20260607170959.823755-2-jt26wzz@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260607170959.823755-1-jt26wzz@gmail.com> References: <20260607170959.823755-1-jt26wzz@gmail.com> 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" From: Andrii Nakryiko [ Upstream commit 9e314f5d8682e1fe6ac214fb34580a238b6fd3c4 ] When performing 32-bit conditional operation operating on lower 32 bits of a full 64-bit register, register full value isn't changed. We just potentially gain new knowledge about that register's lower 32 bits. Unfortunately, __reg_combine_{32,64}_into_{64,32} logic that reg_set_min_max() performs as a last step, can lose information in some cases due to __mark_reg64_unbounded() and __reg_assign_32_into_64(). That's bad and unnecessary. Especially __reg_assign_32_into_64() looks out of place here, because we are not performing zero-extending subregister assignment during conditional jump. Replace __reg_combine_* with reg_bounds_sync(), which derives u64/s64 bounds from u32/s32 and vice versa. For coerce_reg_to_size(), reset subreg bounds for 1- and 2-byte loads and then use reg_bounds_sync() to recover as much information as possible. Acked-by: Eduard Zingerman Signed-off-by: Andrii Nakryiko Acked-by: Shung-Hsi Yu Link: https://lore.kernel.org/r/20231102033759.2541186-10-andrii@kernel.org Signed-off-by: Alexei Starovoitov [ zhenzhong: backport to 6.6.y verifier.c layout. ] Signed-off-by: Zhenzhong Wu --- kernel/bpf/verifier.c | 60 ++++++------------------------------------- 1 file changed, 8 insertions(+), 52 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 0d90236d0..5f94bff12 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2448,51 +2448,6 @@ static void __reg_assign_32_into_64(struct bpf_reg_s= tate *reg) } } =20 -static void __reg_combine_32_into_64(struct bpf_reg_state *reg) -{ - /* special case when 64-bit register has upper 32-bit register - * zeroed. Typically happens after zext or <<32, >>32 sequence - * allowing us to use 32-bit bounds directly, - */ - if (tnum_equals_const(tnum_clear_subreg(reg->var_off), 0)) { - __reg_assign_32_into_64(reg); - } else { - /* Otherwise the best we can do is push lower 32bit known and - * unknown bits into register (var_off set from jmp logic) - * then learn as much as possible from the 64-bit tnum - * known and unknown bits. The previous smin/smax bounds are - * invalid here because of jmp32 compare so mark them unknown - * so they do not impact tnum bounds calculation. - */ - __mark_reg64_unbounded(reg); - } - reg_bounds_sync(reg); -} - -static bool __reg64_bound_s32(s64 a) -{ - return a >=3D S32_MIN && a <=3D S32_MAX; -} - -static bool __reg64_bound_u32(u64 a) -{ - return a >=3D U32_MIN && a <=3D U32_MAX; -} - -static void __reg_combine_64_into_32(struct bpf_reg_state *reg) -{ - __mark_reg32_unbounded(reg); - if (__reg64_bound_s32(reg->smin_value) && __reg64_bound_s32(reg->smax_val= ue)) { - reg->s32_min_value =3D (s32)reg->smin_value; - reg->s32_max_value =3D (s32)reg->smax_value; - } - if (__reg64_bound_u32(reg->umin_value) && __reg64_bound_u32(reg->umax_val= ue)) { - reg->u32_min_value =3D (u32)reg->umin_value; - reg->u32_max_value =3D (u32)reg->umax_value; - } - reg_bounds_sync(reg); -} - /* Mark a register as having a completely unknown (scalar) value. */ static void __mark_reg_unknown(const struct bpf_verifier_env *env, struct bpf_reg_state *reg) @@ -6164,9 +6119,10 @@ static void coerce_reg_to_size(struct bpf_reg_state = *reg, int size) * values are also truncated so we push 64-bit bounds into * 32-bit bounds. Above were truncated < 32-bits already. */ - if (size >=3D 4) - return; - __reg_combine_64_into_32(reg); + if (size < 4) { + __mark_reg32_unbounded(reg); + reg_bounds_sync(reg); + } } =20 static void set_sext64_default_val(struct bpf_reg_state *reg, int size) @@ -14329,13 +14285,13 @@ static void reg_set_min_max(struct bpf_reg_state = *true_reg, tnum_subreg(false_32off)); true_reg->var_off =3D tnum_or(tnum_clear_subreg(true_64off), tnum_subreg(true_32off)); - __reg_combine_32_into_64(false_reg); - __reg_combine_32_into_64(true_reg); + reg_bounds_sync(false_reg); + reg_bounds_sync(true_reg); } else { false_reg->var_off =3D false_64off; true_reg->var_off =3D true_64off; - __reg_combine_64_into_32(false_reg); - __reg_combine_64_into_32(true_reg); + reg_bounds_sync(false_reg); + reg_bounds_sync(true_reg); } } =20 --=20 2.43.0 From nobody Mon Jun 8 04:19:59 2026 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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 3D4DE220F2D for ; Sun, 7 Jun 2026 17:10:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780852226; cv=none; b=Na35BWvdM7lb4KD/se7YvfcrNGoXsFA80fb57gpfll5c0clApyY6GbYUprHf+Nqu8EHL6p58gFvYxjJbW/bqGRqyHOI6wbzoh4gKQd7HogNqV/Qp7MOzdaUaa0n6ieAJOMlIca2Z3bj36wypDoPz65sCaNYaIADvxsXYIH3bOII= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780852226; c=relaxed/simple; bh=R0B+wsENjA8ZzQNVV41noFQrCBBvZhllbql1zNNXSuU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XxX5I+EXRbhltJV0pesPr+N7YyOlRyQxLyhAJ8mdTQuDTRBldROR/Rfkza7Wxvdskdm3h98meB7jX4sHu/lp1pH2STDRPL0Y/mAnTJg29tK9ca/UIXpprywPG+a+D1Xb3G8fLIA3oTgnuvg8mmOcrGcxdmTdXkx9I8t0QQdle78= 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=baU2Q5al; arc=none smtp.client-ip=209.85.214.181 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="baU2Q5al" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2bf125989f2so24881165ad.3 for ; Sun, 07 Jun 2026 10:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780852223; x=1781457023; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9yGPIIhFZdTIFfBstBwjXBL054wfOH0HNW4mEikIzLI=; b=baU2Q5alPeotmoK9isaPu9rDpA+7We4H0jmNGUoj7K64MPkKe5jXMVLJRZysLpkCdf WVETRxojIcHJrsWxQ3BD2KPrhB/Xy/bDAQ7aDowOthkZQFf3qMZi7lnPM6QHwNAikdFn lIZJekZ423/1zPncQRjCyMxkuMF7CVwzRYFd8NYj9G353vPkZcw7uG0t57bFY+cNm7ft 2SaTb6hlnqCibXXLvKS1tZyagFUsWITYHI2xyBbemuizq27Hrp1bL/dWHM01JmqWc6YA 4Luqwj/tiw6utOueeQ5xr76tk/MJFFRCTyyYh1T6rg0zS7Km66UdmGZ5fR2+5gB3cSxC 0IVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780852223; x=1781457023; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=9yGPIIhFZdTIFfBstBwjXBL054wfOH0HNW4mEikIzLI=; b=M1/X2DswbS4sWQECbKef5IuGnae77Mfy3YyAckzimbRLDn0zc63CYR+x0YJBpThS05 DEv86I2SJ6E7On4Zsyoox9DNf+jcJ2IpQFjKT6LDs3UD8kf9teUk6/Icm7BVwBj4v9v6 Bkx+P0Vag4TveFLOk5KS8YYWyBrd9Cxqe+l7QXC+37UyVfEHb78qBPCZ1/DqaK3It/YT FO7ZRTPTIsgyD1f1zB1QWdHIj8fmImL8e/tlNZv2jnpiHQ0jSk+2/Ma+Is5oKKE2TCU/ 7qsftbdVyA12RZBAU6aSShsbP0br1/5ODKK4yfutxdNSbsvTEsIrOJKZ0yn2dSTbkmlq x/9A== X-Forwarded-Encrypted: i=1; AFNElJ9I5rKUYmwgtQiv6k8vvHKMladapJ7Xk3WdkmHI98apsIPV5ty2jakq1+uTx1GgvW8e/ggsWRVLlZSTWJQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwurTi77bezYMlVhNCGMotp9KbAHYyEzVaRbzhGePMmPS8Y4639 Yi0rA7tGAjBMwSKE3HJ+GrEUgSkDf+6D5IFIcW0IRpFRcazVN9sMZSAA X-Gm-Gg: Acq92OEk8IBvYTvzMQvymFeojmrD7sjz7Cfyd3hEIk1y7IsS+MjDCo/2dFFVyIjM27F gTyxl8Alb2qLkx1RVjvR3ApsCOAa/a7vD4WokIqCuTEd8gCwup+MyrYhM9h9K60u4j0c65vMbv7 tPzdzu2aBKyXqJ4HJM32+Pf44r05KgaRP54UJLxMJVWaN1aIOgoXu7+qjXpMKL0Onn6t/TOpeSh r3sbkt6H3z5rJXsfks7iDv7Eppq9grKQk0siByJ0RsNDSgg2dmpSWa/Oy4Eff5hEfGUzL1o+otW lBXzVh7hOVteFKeD0rISTWZ2TTzYuLVsQ9lauruaywSt71OnVvLurJgijGJ6ymFj67qk62FYnlB Rp1tK9nYnZ5c14SdQxil/AtXVbAMnrh9OR5u263AVnS17kr2ouKGtcJQ8jgIz6fiix9z6MZ9HZG CySYqAK8t31SeotKpmjKb9fthSq0VIsLe3jvh+NnXaWQ== X-Received: by 2002:a17:902:d4c6:b0:2c2:5446:30eb with SMTP id d9443c01a7336-2c25446352fmr26955575ad.11.1780852223265; Sun, 07 Jun 2026 10:10:23 -0700 (PDT) Received: from DESKTOP-MUHC17F.lan ([188.253.121.145]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c164f9ed6csm155375265ad.31.2026.06.07.10.10.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jun 2026 10:10:22 -0700 (PDT) From: Zhenzhong Wu To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, menglong8.dong@gmail.com, eddyz87@gmail.com, shung-hsi.yu@suse.com, stable@vger.kernel.org, mykolal@fb.com, tamird@kernel.org Subject: [PATCH stable 6.6.y v2 2/3] bpf: make the verifier tracks the "not equal" for regs Date: Mon, 8 Jun 2026 01:09:57 +0800 Message-ID: <20260607170959.823755-3-jt26wzz@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260607170959.823755-1-jt26wzz@gmail.com> References: <20260607170959.823755-1-jt26wzz@gmail.com> 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" From: Menglong Dong [ Upstream commit d028f87517d6775dccff4ddbca2740826f9e53f1 ] We can derive useful information for BPF_JNE when one side is a constant and the constant is exactly at the edge of the other register range. For example, a > 0 can be compiled as a jump if a =3D=3D 0. The equal branch marks the register as known zero, but the fallthrough branch also needs to preserve that the register is not zero. Without this, the range can remain [0, max] and later verifier state pruning can keep an impossible scalar path. The upstream fix lives in regs_refine_cond_op(). The 6.6.y verifier still uses the older reg_set_min_max() layout, so express the same branch-edge refinement there: for BPF_JEQ, preserve the known-equal true branch and exclude the constant from false_reg; for BPF_JNE, preserve the known-equal false branch and exclude the constant from true_reg. Signed-off-by: Menglong Dong Acked-by: Andrii Nakryiko Acked-by: Shung-Hsi Yu Link: https://lore.kernel.org/r/20231219134800.1550388-2-menglong8.dong@gma= il.com Signed-off-by: Alexei Starovoitov [ zhenzhong: backport to 6.6.y reg_set_min_max() layout. ] Signed-off-by: Zhenzhong Wu --- kernel/bpf/verifier.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 5f94bff12..de4f46796 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -14169,18 +14169,50 @@ static void reg_set_min_max(struct bpf_reg_state = *true_reg, if (is_jmp32) { __mark_reg32_known(true_reg, val32); true_32off =3D tnum_subreg(true_reg->var_off); + if (false_reg->u32_min_value =3D=3D val32) + false_reg->u32_min_value++; + if (false_reg->u32_max_value =3D=3D val32) + false_reg->u32_max_value--; + if (false_reg->s32_min_value =3D=3D sval32) + false_reg->s32_min_value++; + if (false_reg->s32_max_value =3D=3D sval32) + false_reg->s32_max_value--; } else { ___mark_reg_known(true_reg, val); true_64off =3D true_reg->var_off; + if (false_reg->umin_value =3D=3D val) + false_reg->umin_value++; + if (false_reg->umax_value =3D=3D val) + false_reg->umax_value--; + if (false_reg->smin_value =3D=3D sval) + false_reg->smin_value++; + if (false_reg->smax_value =3D=3D sval) + false_reg->smax_value--; } break; case BPF_JNE: if (is_jmp32) { __mark_reg32_known(false_reg, val32); false_32off =3D tnum_subreg(false_reg->var_off); + if (true_reg->u32_min_value =3D=3D val32) + true_reg->u32_min_value++; + if (true_reg->u32_max_value =3D=3D val32) + true_reg->u32_max_value--; + if (true_reg->s32_min_value =3D=3D sval32) + true_reg->s32_min_value++; + if (true_reg->s32_max_value =3D=3D sval32) + true_reg->s32_max_value--; } else { ___mark_reg_known(false_reg, val); false_64off =3D false_reg->var_off; + if (true_reg->umin_value =3D=3D val) + true_reg->umin_value++; + if (true_reg->umax_value =3D=3D val) + true_reg->umax_value--; + if (true_reg->smin_value =3D=3D sval) + true_reg->smin_value++; + if (true_reg->smax_value =3D=3D sval) + true_reg->smax_value--; } break; case BPF_JSET: --=20 2.43.0 From nobody Mon Jun 8 04:19:59 2026 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.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 4D51D2D0C7B for ; Sun, 7 Jun 2026 17:10:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780852231; cv=none; b=ERi1o2XrXIsEsNHVnNgKb3yvYl4SiVHnipNOq7N/DPNk1O/2Lgzaep9RbgGVZZgCI7QfJSI4/DjIob9S0vKZ99cGVSa2qwFOuxk9Ge1skCLIm93MVtLhztzGgfAXS/DC3VDskYPiMl4VstoymCf2Pvdpg7dniR1agjTg845L278= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780852231; c=relaxed/simple; bh=POr7Ix06Wp1uWzM/s/uHnlsY2+YTVLr9bOr1tz902ps=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WHo2MNEUprKFpHmZl/QDlW6YbDk11OLKjMGp4Wy6ABYZh/Gzvo7iaud5g84pQ9eeeyDjy2timtZ1MvYhnOv7JZDxeImqZgxQDVdVD4A5cqFwvOyTsZRHBQr8/PxjdyJzxFnyzMK7Tu2sE9tlaqSsdI9RXd5UcMs3UvjqbQpKhSg= 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=GOnqxaAQ; arc=none smtp.client-ip=209.85.214.173 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="GOnqxaAQ" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2c0c1e0d00bso35075875ad.0 for ; Sun, 07 Jun 2026 10:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780852229; x=1781457029; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bTfbPBlxFmhjxsli3uFXWEfIKIHGvct1qlkSlFL8qW4=; b=GOnqxaAQGzQVjv888xjQFkCye5CGOIV+20umJK1IzH5A4zf4/fbK7of3ePnQhItiMx 9C/rDthzXWuRA0H6mWLZ2sorIAqRbbjUgUzcRhsjIbs0oZ1luD/smsD00xAaY4OzACLl zivDjLU09inS7/B6LEfy8AuhLwV0vG0yV3FkVQ8xyNMqISLIcRhyiXZNbRtz2lC1uDXe a+5TLg7SgMEss/QL2NSKkESL+T03UyF+JwIBn2WgPAi0T0Z3aO7vk8bimoOSQCqr6sal IXIrjWTpWTIiWDPao/oR3BfvOatxLkmuCuhGHy+eUERJODWpIlTGL2RoiyVrEYWm+0s2 KSZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780852229; x=1781457029; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bTfbPBlxFmhjxsli3uFXWEfIKIHGvct1qlkSlFL8qW4=; b=SXTffi4ioZiu2ed+v+PH2rlrz/33Lbx/umMDqFVEjMzzSUZQPEED+lU/2nnUZmlDND j9w2bq7KGLqcCHYbL+kEFx1acO5iLn4efxne4t/Yr1dub6Jvk8TvUKcYOhVbZ5FLZoOW BCyv7gXXuovNZ57TU+h6RP2cWM0/poutH7rMLju64KZKFLL9iKipFCc4c9kjAKzkfl7O IDdgbjj5MSD27sLBxOiL5Qjj/mBwJ2mDNf3ErYCpsZNwxbfFtjStFkHwJr//x44BP2pd FwjBTk6Pa0/PJrpwJWdjnK0I6KMXm02ui2d56REIqWeLGHSG1Pb0Qj555XNaZuVsOqp9 DKRA== X-Forwarded-Encrypted: i=1; AFNElJ/Cy4zoC6/+Jxa7OImD4ngvn7gDe1k02UUSZX0KfWOSO7E+1ghBDxx79bFtkcHYZXUnjQdVJ1xLYgy9reo=@vger.kernel.org X-Gm-Message-State: AOJu0YxGxo0a7COmVeFlpk6b61IWGq0oBA4i+NE+IEFzXHPYnKQnr/tF +CpY9ttJo/Bbx5wM6Ni+f8B0mJRhOnfGpi4P5D77Pm9IjaxqbpOszkc9 X-Gm-Gg: Acq92OEQoW1GkKz95saWSYDYFHFXQJeeRqUpaGLX47DI/SnshAnuRsaczb1CSpBV9sQ ZFLdLN2w3GF1lYCyh/AZCprxFaXYyMnGD/L9GPJQvmWxOa1qsoiY87XMLZZUhWb2zzu8MUBNSGw iM/DSeH20PcERIXqd36XVFSoZwFhprepJRZm000YYFw0SR0nB9/YnlUD7CDvxBzPuhBB6ERkoO4 xD4rmGd6m3Xm3IT/88gLrJjyPfoPNXCQTwAQ10/42jpltCA922jMKzf/4jcjd2I0rL1Kz5caB8Q lRLAoQbM6ZZLhhD6BsJ5WLYpPtDh93aZ+/fB4pCRROcs84dxlrZUWadLVl+j4s34x6NB9k08tqc gYeH1VDftK/lBnF2rOHkIHzfw0IdyMESEqS9yh3IM4Oz4FdcORChsRT+C5DvgMgfjP23GEY9oxe zhQkvQ+1oH7vqPrJgyXT+J7CeU3Dkn7KG25bnZGjJinA== X-Received: by 2002:a17:902:ef08:b0:2b9:6458:1a2c with SMTP id d9443c01a7336-2c1e820e30bmr150565325ad.13.1780852229364; Sun, 07 Jun 2026 10:10:29 -0700 (PDT) Received: from DESKTOP-MUHC17F.lan ([188.253.121.145]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c164f9ed6csm155375265ad.31.2026.06.07.10.10.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jun 2026 10:10:28 -0700 (PDT) From: Zhenzhong Wu To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, menglong8.dong@gmail.com, eddyz87@gmail.com, shung-hsi.yu@suse.com, stable@vger.kernel.org, mykolal@fb.com, tamird@kernel.org Subject: [PATCH stable 6.6.y v2 3/3] selftests/bpf: add helper retval linked scalar pruning test Date: Mon, 8 Jun 2026 01:09:58 +0800 Message-ID: <20260607170959.823755-4-jt26wzz@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260607170959.823755-1-jt26wzz@gmail.com> References: <20260607170959.823755-1-jt26wzz@gmail.com> 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" Add a verifier test case covering a pruning bug where a helper return value and another scalar become linked by scalar id on one path. A later branch can then let the verifier explore an impossible continuation and prune the real success path. The test uses bpf_skb_load_bytes() to create a helper return value in R0 and a scalar derived from the tc test packet length. It then links the two scalars on one path and checks that the later branch keeps the reachable success path. Signed-off-by: Zhenzhong Wu --- .../selftests/bpf/progs/verifier_reg_equal.c | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/tools/testing/selftests/bpf/progs/verifier_reg_equal.c b/tools= /testing/selftests/bpf/progs/verifier_reg_equal.c index dc1d8c30f..269b2af50 100644 --- a/tools/testing/selftests/bpf/progs/verifier_reg_equal.c +++ b/tools/testing/selftests/bpf/progs/verifier_reg_equal.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 =20 #include +#include #include #include "bpf_misc.h" =20 @@ -55,4 +56,38 @@ l1_%=3D: exit; \ : __clobber_all); } =20 +SEC("tc") +__description("helper retval linked scalar pruning") +__success __retval(0) +__naked void helper_retval_linked_scalar_pruning(void) +{ + asm volatile (" \ + r7 =3D *(u32 *)(r1 + %[__sk_buff_data_end]); \ + r5 =3D *(u32 *)(r1 + %[__sk_buff_data]); \ + r7 -=3D r5; \ + r2 =3D 0; \ + r3 =3D r10; \ + r3 +=3D -8; \ + r4 =3D 1; \ + call %[bpf_skb_load_bytes]; \ + r6 =3D 1; \ + if r0 =3D=3D 0 goto l0_%=3D; \ + r7 =3D r0; \ +l0_%=3D: if r0 !=3D 0 goto l1_%=3D; \ + r7 <<=3D 32; \ + r7 >>=3D 32; \ + r6 =3D 1; \ + if r7 !=3D %[test_data_len] goto l1_%=3D; \ + r0 =3D 0; \ + exit; \ +l1_%=3D: r0 =3D r6; \ + exit; \ +" : + : __imm(bpf_skb_load_bytes), + __imm_const(__sk_buff_data, offsetof(struct __sk_buff, data)), + __imm_const(__sk_buff_data_end, offsetof(struct __sk_buff, data_end)), + __imm_const(test_data_len, TEST_DATA_LEN) + : __clobber_all); +} + char _license[] SEC("license") =3D "GPL"; --=20 2.43.0