> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index ed7ba0e6a9ce..514322aca6ed 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -14758,6 +14758,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;
> + }
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 by using operations
like scalar -= untrusted_ptr or scalar ^= untrusted_ptr.
When an attacker uses these alternative operations, the code will:
1. Bypass the new BPF_ADD check added by this patch
2. Call adjust_ptr_min_max_vals() with the untrusted pointer
3. Hit the early return for untrusted PTR_TO_MEM in
adjust_ptr_min_max_vals()
4. Return success without updating the scalar's verifier state
This creates the same verifier state desynchronization vulnerability that
the patch was meant to fix. The scalar register's tracked bounds remain
stale while its actual runtime value has been manipulated by the pointer
value.
Can this verifier state desynchronization be leveraged to achieve
out-of-bounds access?
This concern was raised by [email protected] in the v1 review:
https://lore.kernel.org/bpf/[email protected]/
The author has not responded to this concern.
> err = mark_chain_precision(env, insn->dst_reg);
> if (err)
> return err;
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27215521040
