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

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

[Nuoqi Gui]

scalar += rdonly_untrusted_mem reaches adjust_ptr_min_max_vals() with the
pointer as the source register. The untrusted PTR_TO_MEM case returns there
without updating the scalar destination, leaving stale verifier state.

Reject that addition before the early return. Pointer += scalar remains
handled by the existing untrusted-memory rule.

Patch 1 adds the verifier rejection. Patch 2 adds a verifier regression
test for scalar += bpf_rdonly_cast(..., 0).

Validation:

  unpatched bpf-next 8496d9020ff3:
    BPF_PROG_LOAD -> fd=4 errno=0
    RESULT: verifier ACCEPTED (unexpected_accept)

  patched bpf-next 8496d9020ff3 + this series:
    BPF_PROG_LOAD -> fd=-1 errno=13 (Permission denied)
    R1 tried to add from rdonly_untrusted_mem to scalar
    RESULT: verifier REJECTED as expected

Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
Nuoqi Gui (2):
      bpf: Reject scalar addition from untrusted memory
      selftests/bpf: Cover scalar addition from rdonly untrusted memory

 kernel/bpf/verifier.c                                   |  8 ++++++++
 .../testing/selftests/bpf/progs/mem_rdonly_untrusted.c  | 17 +++++++++++++++++
 2 files changed, 25 insertions(+)
---
base-commit: 8496d9020ff37a33c2a7b2fc84350fd03ffbde78
change-id: 20260609-f01-03-scalar-add-bpf-next-0ccf8a54f338

Best regards,
--  
Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>

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

[Nuoqi Gui]

scalar += rdonly_untrusted_mem reaches adjust_ptr_min_max_vals() with the
pointer as the source register. The untrusted PTR_TO_MEM case returns there
without updating the scalar destination, leaving stale verifier state.

Reject that addition before the early return. Pointer += scalar remains
handled by the existing untrusted-memory rule.

Fixes: f2362a57aeff ("bpf: allow void* cast using bpf_rdonly_cast()")
Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
 kernel/bpf/verifier.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index c8d980fdd709..c6b350f9585a 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;

-- 
2.34.1

[PATCH bpf-next 2/2] selftests/bpf: Cover scalar addition from rdonly untrusted memory

[Nuoqi Gui]

Add a verifier test for scalar += rdonly_untrusted_mem. The program gets a
read-only untrusted memory value from bpf_rdonly_cast(..., 0). It then adds
that value to a scalar destination. The verifier should reject this instead
of preserving stale scalar state.

Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
 .../testing/selftests/bpf/progs/mem_rdonly_untrusted.c  | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c b/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c
index 5b4453747c23..303b8ed3e70b 100644
--- a/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c
+++ b/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c
@@ -77,6 +77,23 @@ int offset_not_tracked(void *ctx)
 	return s;
 }
 
+SEC("socket")
+__failure
+__msg("R1 tried to add from rdonly_untrusted_mem to scalar")
+__naked void scalar_add_not_ok(void)
+{
+	asm volatile ("r1 = 0;"
+	"r2 = 0;"
+	"call %[bpf_rdonly_cast];"
+	"r1 = 0;"
+	"r1 += r0;"
+	"r0 = 0;"
+	"exit;"
+	:
+	: __imm(bpf_rdonly_cast)
+	: __clobber_all);
+}
+
 SEC("socket")
 __failure
 __msg("cannot write into rdonly_untrusted_mem")

-- 
2.34.1

Re: [PATCH bpf-next 2/2] selftests/bpf: Cover scalar addition from rdonly untrusted memory

[sashiko-bot]

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

New issues:
- [Low] The newly added selftest only verifies the rejection of `BPF_ADD` with untrusted pointers, missing coverage for other vulnerable ALU operations.

Pre-existing issues:
- [Critical] This problem wasn't introduced by this patch, but the verifier incorrectly allows scalar operations (like BPF_SUB, BPF_AND, BPF_XOR) with untrusted pointers, leading to arbitrary kernel memory read/write vulnerabilities.
--

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

selftests/bpf: Cover scalar addition from rdonly untrusted memory

This commit adds a BPF verifier selftest for scalar addition with
rdonly_untrusted_mem. It checks if the verifier properly rejects adding an
untrusted memory value to a scalar destination.

> diff --git a/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c b/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c
> index 5b4453747c230..303b8ed3e70b6 100644
> --- a/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c
> +++ b/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c
[ ... ]
> @@ -77,6 +77,23 @@ int offset_not_tracked(void *ctx)
>  	return s;
>  }
>  
> +SEC("socket")
> +__failure
> +__msg("R1 tried to add from rdonly_untrusted_mem to scalar")
> +__naked void scalar_add_not_ok(void)
> +{
> +	asm volatile ("r1 = 0;"
> +	"r2 = 0;"
> +	"call %[bpf_rdonly_cast];"
> +	"r1 = 0;"
> +	"r1 += r0;"

[Severity: Critical]
This is a pre-existing issue, but the verifier incorrectly allows scalar
operations like subtraction, bitwise AND, and XOR with untrusted pointers,
leading to arbitrary kernel memory read/write vulnerabilities.

In kernel/bpf/verifier.c:adjust_reg_min_max_vals(), the check explicitly
tests for addition:

	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", ...);

For other ALU operations, the verifier delegates to
adjust_ptr_min_max_vals(), which returns early:

	if (base_type(ptr_reg->type) == PTR_TO_MEM &&
	    (ptr_reg->type & PTR_UNTRUSTED))
		return 0;

This early return bypasses all opcode validation and leaves the destination
register unmodified as a scalar value with its original bounds. At runtime,
the register receives the result of the pointer arithmetic and can be used
to bypass bounds checks.

Could the verifier be updated to properly reject all invalid ALU operations
on untrusted pointers?

[Severity: Low]
Is it possible to expand this selftest to cover other ALU operations?

Because the verifier code currently ignores operations other than addition,
adding tests like scalar_sub_not_ok or scalar_xor_not_ok would ensure these
operations are also correctly rejected and expose the missing verifier checks.

> +	"r0 = 0;"
> +	"exit;"
> +	:
> +	: __imm(bpf_rdonly_cast)
> +	: __clobber_all);
> +}

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

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

[sashiko-bot]

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

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

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

> 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 sashiko-bot@kernel.org in the v1 review:
https://lore.kernel.org/bpf/20260609151019.678141F00893@smtp.kernel.org/

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

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

[Eduard Zingerman]

On Tue, 2026-06-09 at 22:55 +0800, Nuoqi Gui wrote:
> scalar += rdonly_untrusted_mem reaches adjust_ptr_min_max_vals() with the
> pointer as the source register. The untrusted PTR_TO_MEM case returns there
> without updating the scalar destination, leaving stale verifier state.
> 
> Reject that addition before the early return. Pointer += scalar remains
> handled by the existing untrusted-memory rule.
> 
> Fixes: f2362a57aeff ("bpf: allow void* cast using bpf_rdonly_cast()")
> Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
> ---
>  kernel/bpf/verifier.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index c8d980fdd709..c6b350f9585a 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;

Should the fix be like this:

  diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
  index 7d27ba396d32..9c85dd680a46 100644
  --- a/kernel/bpf/verifier.c
  +++ b/kernel/bpf/verifier.c
  @@ -13593,8 +13593,10 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
           * Accesses to untrusted PTR_TO_MEM are done through probe
           * instructions, hence no need to track offsets.
           */
  -       if (base_type(ptr_reg->type) == PTR_TO_MEM && (ptr_reg->type & PTR_UNTRUSTED))
  +       if (base_type(ptr_reg->type) == PTR_TO_MEM && (ptr_reg->type & PTR_UNTRUSTED)) {
  +               *dst_reg = *ptr_reg;
                  return 0;
  +       }
   
          switch (base_type(ptr_reg->type)) {
          case PTR_TO_CTX:

Instead?

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

[Emil Tsalapatis]

On Tue Jun 9, 2026 at 1:01 PM EDT, Eduard Zingerman wrote:
> On Tue, 2026-06-09 at 22:55 +0800, Nuoqi Gui wrote:
>> scalar += rdonly_untrusted_mem reaches adjust_ptr_min_max_vals() with the
>> pointer as the source register. The untrusted PTR_TO_MEM case returns there
>> without updating the scalar destination, leaving stale verifier state.
>> 
>> Reject that addition before the early return. Pointer += scalar remains
>> handled by the existing untrusted-memory rule.
>> 
>> Fixes: f2362a57aeff ("bpf: allow void* cast using bpf_rdonly_cast()")
>> Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
>> ---
>>  kernel/bpf/verifier.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index c8d980fdd709..c6b350f9585a 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;
>
> Should the fix be like this:
>
>   diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>   index 7d27ba396d32..9c85dd680a46 100644
>   --- a/kernel/bpf/verifier.c
>   +++ b/kernel/bpf/verifier.c
>   @@ -13593,8 +13593,10 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
>            * Accesses to untrusted PTR_TO_MEM are done through probe
>            * instructions, hence no need to track offsets.
>            */
>   -       if (base_type(ptr_reg->type) == PTR_TO_MEM && (ptr_reg->type & PTR_UNTRUSTED))
>   +       if (base_type(ptr_reg->type) == PTR_TO_MEM && (ptr_reg->type & PTR_UNTRUSTED)) {
>   +               *dst_reg = *ptr_reg;
>                   return 0;
>   +       }
>    
>           switch (base_type(ptr_reg->type)) {
>           case PTR_TO_CTX:
>
> Instead?

Seconded, AFAICT there is no reason to fail verification since we just
the pointer's value to the scalar. Whether the operation makes sense is
up to the programmer to decide.