Re: [PATCH bpf-next 1/2] bpf: Reject scalar addition from untrusted memory

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] The patch only prevents `scalar += untrusted_ptr` (BPF_ADD) but fails to reject other ALU operations like `BPF_SUB`, `BPF_XOR`, and `BPF_MUL`. This allows attackers to trivially bypass the new check and trigger the exact same verifier type-confusion bug.
--

commit cfb0cd2267dc0023c68b5a917127e38cfcf1a758
Author: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>

bpf: Reject scalar addition from untrusted memory

This commit attempts to fix a verifier issue where an untrusted PTR_TO_MEM
is added to a scalar, which would previously return early and leave the
verifier state stale. It rejects the addition before the early return,
while leaving pointer += scalar handled by existing rules.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index c8d980fdd7099..c6b350f9585ae 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

> @@ -14823,6 +14823,14 @@ static int adjust_reg_min_max_vals(struct bpf_verifier_env *env,
>  				 * This is legal, but we have to reverse our
>  				 * src/dest handling in computing the range
>  				 */
> +				if (opcode == BPF_ADD &&
> +				    base_type(src_reg->type) == 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 = mark_chain_precision(env, insn->dst_reg);
>  				if (err)
>  					return err;

[Severity: Critical]
This isn't a bug introduced by this patch, but by restricting this check
explicitly to BPF_ADD, does this leave other ALU operations like BPF_SUB,
BPF_XOR, or BPF_MUL vulnerable to the same regression?

If an attacker uses BPF_SUB or BPF_XOR (e.g., scalar ^= untrusted_ptr),
the new check is bypassed. The code then falls through to calling
adjust_ptr_min_max_vals(), where it hits an early return for untrusted
PTR_TO_MEM:

kernel/bpf/verifier.c:adjust_ptr_min_max_vals() {
    ...
    if (base_type(ptr_reg->type) == PTR_TO_MEM && (ptr_reg->type & PTR_UNTRUSTED))
        return 0;
    ...
}

This early return skips the validation block that would normally reject these
unsupported operations on pointers. This accepts the instruction without
updating the scalar's verifier bounds state, while its actual runtime value
is manipulated by the pointer.

Can this verifier state desynchronization be leveraged to achieve
out-of-bounds access?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-f01-03-scalar-add-bpf-next-v1-0-e6212e274155@mails.tsinghua.edu.cn?part=1