[PATCH AUTOSEL 6.15 081/118] bpf: Use proper type to calculate bpf_raw_tp_null_args.mask index

[Sasha Levin <sashal@kernel.org>]

From: Shung-Hsi Yu <shung-hsi.yu@suse.com>

[ Upstream commit 53ebef53a657d7957d35dc2b953db64f1bb28065 ]

The calculation of the index used to access the mask field in 'struct
bpf_raw_tp_null_args' is done with 'int' type, which could overflow when
the tracepoint being attached has more than 8 arguments.

While none of the tracepoints mentioned in raw_tp_null_args[] currently
have more than 8 arguments, there do exist tracepoints that had more
than 8 arguments (e.g. iocost_iocg_forgive_debt), so use the correct
type for calculation and avoid Smatch static checker warning.

Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/bpf/20250418074946.35569-1-shung-hsi.yu@suse.com

Closes: https://lore.kernel.org/r/843a3b94-d53d-42db-93d4-be10a4090146@stanley.mountain/
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

Now I have enough context to analyze this commit: **Analysis:** **YES**
- This commit should be backported to stable kernel trees. **Extensive
Explanation:** ## Issue Description The commit fixes a potential integer
overflow in the BPF BTF subsystem. The bug is in lines 6830 and 6833 of
`kernel/bpf/btf.c` where the calculation `(arg capability_test
capability_test.c f2fs_folio_analysis.md ipv4_multipath_analysis.md
ipv6_route_allocation_rcu_analysis.md ixgbe_e610_set_phys_id_analysis.md
linux lpfc_timeout_analysis.md rtl_bb_delay_analysis.md
rtw89_mlo_analysis.md tcp_multipath_load_balance_analysis.md
type_size_check type_size_check.c veth_driver_analysis.md 4)` is done
with `int` type when `arg` can theoretically be large enough to cause
overflow. ## Code Analysis 1. **Variable Types**: - `arg` is declared as
`u32` (from `btf_ctx_arg_idx` return type) - The shift operation was
using `int` arithmetic: `(0x1 << (arg capability_test capability_test.c
f2fs_folio_analysis.md ipv4_multipath_analysis.md
ipv6_route_allocation_rcu_analysis.md ixgbe_e610_set_phys_id_analysis.md
linux lpfc_timeout_analysis.md rtl_bb_delay_analysis.md
rtw89_mlo_analysis.md tcp_multipath_load_balance_analysis.md
type_size_check type_size_check.c veth_driver_analysis.md 4))` - The fix
changes it to `unsigned long long`: `(0x1ULL << (arg capability_test
capability_test.c f2fs_folio_analysis.md ipv4_multipath_analysis.md
ipv6_route_allocation_rcu_analysis.md ixgbe_e610_set_phys_id_analysis.md
linux lpfc_timeout_analysis.md rtl_bb_delay_analysis.md
rtw89_mlo_analysis.md tcp_multipath_load_balance_analysis.md
type_size_check type_size_check.c veth_driver_analysis.md 4))` 2. **The
Overflow Scenario**: - When `arg >= 8`, the expression `(arg
capability_test capability_test.c f2fs_folio_analysis.md
ipv4_multipath_analysis.md ipv6_route_allocation_rcu_analysis.md
ixgbe_e610_set_phys_id_analysis.md linux lpfc_timeout_analysis.md
rtl_bb_delay_analysis.md rtw89_mlo_analysis.md
tcp_multipath_load_balance_analysis.md type_size_check type_size_check.c
veth_driver_analysis.md 4)` could be >= 32 - Shifting by >= 32 bits on a
32-bit `int` causes undefined behavior - Even on 64-bit systems, large
values could overflow the intermediate calculation 3. **Specific
Changes**: ```c // Before (vulnerable): if (raw_tp_null_args[i].mask &
(0x1 << (arg capability_test capability_test.c f2fs_folio_analysis.md
ipv4_multipath_analysis.md ipv6_route_allocation_rcu_analysis.md
ixgbe_e610_set_phys_id_analysis.md linux lpfc_timeout_analysis.md
rtl_bb_delay_analysis.md rtw89_mlo_analysis.md
tcp_multipath_load_balance_analysis.md type_size_check type_size_check.c
veth_driver_analysis.md 4))) if (raw_tp_null_args[i].mask & (0x2 << (arg
capability_test capability_test.c f2fs_folio_analysis.md
ipv4_multipath_analysis.md ipv6_route_allocation_rcu_analysis.md
ixgbe_e610_set_phys_id_analysis.md linux lpfc_timeout_analysis.md
rtl_bb_delay_analysis.md rtw89_mlo_analysis.md
tcp_multipath_load_balance_analysis.md type_size_check type_size_check.c
veth_driver_analysis.md 4))) // After (fixed): if
(raw_tp_null_args[i].mask & (0x1ULL << (arg capability_test
capability_test.c f2fs_folio_analysis.md ipv4_multipath_analysis.md
ipv6_route_allocation_rcu_analysis.md ixgbe_e610_set_phys_id_analysis.md
linux lpfc_timeout_analysis.md rtl_bb_delay_analysis.md
rtw89_mlo_analysis.md tcp_multipath_load_balance_analysis.md
type_size_check type_size_check.c veth_driver_analysis.md 4))) if
(raw_tp_null_args[i].mask & (0x2ULL << (arg capability_test
capability_test.c f2fs_folio_analysis.md ipv4_multipath_analysis.md
ipv6_route_allocation_rcu_analysis.md ixgbe_e610_set_phys_id_analysis.md
linux lpfc_timeout_analysis.md rtl_bb_delay_analysis.md
rtw89_mlo_analysis.md tcp_multipath_load_balance_analysis.md
type_size_check type_size_check.c veth_driver_analysis.md 4))) ``` ##
Why This Should Be Backported 1. **Bug Fix**: This is a clear bug fix
addressing undefined behavior that could cause incorrect BPF program
verification. 2. **Small and Contained**: The fix is minimal - only
changes two lines by adding `ULL` suffix to ensure 64-bit arithmetic. 3.
**No Side Effects**: The change maintains the same logic but uses proper
types, eliminating undefined behavior without changing functionality. 4.
**Critical Subsystem**: This affects BPF verification, which is
security-critical. Incorrect verification could lead to security issues.
5. **Static Analysis Detection**: The commit was triggered by a Smatch
static checker warning, indicating this is a real issue that static
analysis tools flag. 6. **Potential Real-World Impact**: While the
commit mentions no current tracepoints have >8 arguments, the code path
could be triggered by future tracepoints or module tracepoints, making
this a defensive fix. 7. **Follows Stable Criteria**: - Important bugfix
✓ - Minimal risk ✓ - No architectural changes ✓ - Confined to BPF
subsystem ✓ ## Comparison with Similar Commits Looking at the historical
examples, this commit is most similar to "Similar Commit #5" which was
marked as "Backport Status: YES" - it's a small type safety fix in BPF
BTF code that prevents undefined behavior. The fix prevents a subtle but
potentially serious issue in BPF program verification, making it an
excellent candidate for stable backporting.

 kernel/bpf/btf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 16ba36f34dfab..656ee11aff676 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -6829,10 +6829,10 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
 			/* Is this a func with potential NULL args? */
 			if (strcmp(tname, raw_tp_null_args[i].func))
 				continue;
-			if (raw_tp_null_args[i].mask & (0x1 << (arg * 4)))
+			if (raw_tp_null_args[i].mask & (0x1ULL << (arg * 4)))
 				info->reg_type |= PTR_MAYBE_NULL;
 			/* Is the current arg IS_ERR? */
-			if (raw_tp_null_args[i].mask & (0x2 << (arg * 4)))
+			if (raw_tp_null_args[i].mask & (0x2ULL << (arg * 4)))
 				ptr_err_raw_tp = true;
 			break;
 		}
-- 
2.39.5