All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: <sashiko-reviews@lists.linux.dev>,
	"Eduard Zingerman" <eddyz87@gmail.com>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf 7/8] bpf: mark the zero register precise for a register-form NULL check
Date: Fri, 04 Sep 2026 13:11:05 +0200	[thread overview]
Message-ID: <DL6HIRCS6H45.1323PCUH1EB9T@gmail.com> (raw)
In-Reply-To: <20260904085722.7BF111F00A3D@smtp.kernel.org>

On Fri Sep 4, 2026 at 10:57 AM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] The verifier fails to mark scalar registers precise when `bpf_register_is_null()` is used to satisfy a nullable pointer argument or kptr store.
> --
>
> commit c721af04f2965a6636b3260c058c2531da5526e0
> Author: Eduard Zingerman <eddyz87@gmail.com>
>
> bpf: mark the zero register precise for a register-form NULL check
>
> This patch fixes a bug in check_cond_jmp_op() where comparing a nullable
> pointer to a scalar known to be zero fails to mark the scalar register
> precise. This prevents malicious state pruning where an imprecise scalar
> could bypass safety checks and lead to a forged pointer dereference.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 303368460ec10..fde5d046b6e32 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -17052,6 +17052,15 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
>>  	    type_may_be_null(dst_reg->type) &&
>>  	    ((BPF_SRC(insn->code) == BPF_K && insn->imm == 0) ||
>>  	     (BPF_SRC(insn->code) == BPF_X && bpf_register_is_null(src_reg)))) {
>> +		/*
>> +		 * For BPF_X the zero is a property of this execution path,
>> +		 * hence src_reg has to be precise.
>> +		 */
>> +		if (BPF_SRC(insn->code) == BPF_X) {
>> +			err = mark_chain_precision(env, insn->src_reg);
>> +			if (err)
>> +				return err;
>> +		}
>
> [Severity: Critical]
> This is a pre-existing issue and not a bug introduced by this patch, but
> since this change addresses missing precision tracking for zero-valued
> scalar registers, do we need similar mark_chain_precision() calls in
> other places that use bpf_register_is_null() to satisfy pointer checks?
>
> For example, in check_map_kptr_access(), we bypass type checking when the
> register is a scalar zero:
>
> kernel/bpf/verifier.c:check_map_kptr_access() {
>     ...
>     if (!bpf_register_is_null(val_reg) &&
>         map_kptr_match_type(env, kptr_field, val_reg, value_regno))
>     ...
> }

This should be addressed by the following fix:
https://lore.kernel.org/bpf/20260904104203.345917-6-memxor@gmail.com.

>
> Similar bypasses without precision marking appear in several other argument
> checkers:
>
> kernel/bpf/verifier.c:check_func_arg() {
>     ...
>     if (bpf_register_is_null(reg) && type_may_be_null(arg_type))
>         /* A NULL register has a SCALAR_VALUE type, so skip
>          * type checking.
>          */
>         goto skip_type_check;
>     ...
>     if (type_may_be_null(arg_type) && bpf_register_is_null(reg))
>         return 0;
>     ...
> }
>
> kernel/bpf/verifier.c:check_kfunc_args() {
>     ...
>     if (bpf_register_is_null(reg) && type_may_be_null(kf_arg_type))
>         continue;
>     ...
> }
>
> kernel/bpf/verifier.c:check_mem_reg() {
>     ...
>     if (bpf_register_is_null(reg))
>         return 0;
>     ...
> }
>

The rest need investigation...

> Could an attacker use these paths in a similar way to the vulnerability
> described in your commit message?
>
> If a branch assigns a scalar 0, passes it to one of these functions
> (leaving it imprecise), and another branch merges with an arbitrary kernel
> address, wouldn't states_equal() incorrectly prune the malicious branch
> because regsafe() returns true for imprecise scalars?
>
>>  		/* Mark all identical registers in each branch as either
>>  		 * safe or unknown depending R == 0 or R != 0 conditional.
>>  		 */


  reply	other threads:[~2026-09-04 11:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  8:33 [PATCH bpf 1/8] bpf: don't infer non-NULL from a pointer with an unbounded offset Eduard Zingerman
2026-09-04  8:33 ` [PATCH bpf 2/8] selftests/bpf: no non-NULL inference from unbounded offset pointers Eduard Zingerman
2026-09-04  8:33 ` [PATCH bpf 3/8] bpf: don't resurrect a scalar id dropped by collect_linked_regs() Eduard Zingerman
2026-09-04  8:33 ` [PATCH bpf 4/8] selftests/bpf: check the linked regs cap for the compared register Eduard Zingerman
2026-09-04  8:33 ` [PATCH bpf 5/8] bpf: don't predict JMP32 pointer vs zero comparisons Eduard Zingerman
2026-09-04  8:33 ` [PATCH bpf 6/8] selftests/bpf: check that JMP32 pointer vs zero jumps are not predicted Eduard Zingerman
2026-09-04  8:33 ` [PATCH bpf 7/8] bpf: mark the zero register precise for a register-form NULL check Eduard Zingerman
2026-09-04  8:57   ` sashiko-bot
2026-09-04 11:11     ` Kumar Kartikeya Dwivedi [this message]
2026-09-04  8:33 ` [PATCH bpf 8/8] selftests/bpf: no non-NULL inference from an imprecise zero register Eduard Zingerman
2026-09-04 11:10 ` [PATCH bpf 1/8] bpf: don't infer non-NULL from a pointer with an unbounded offset patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DL6HIRCS6H45.1323PCUH1EB9T@gmail.com \
    --to=memxor@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.