All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: <bot+bpf-ci@kernel.org>, <alexis.lothore@bootlin.com>,
	<ast@kernel.org>, <daniel@iogearbox.net>,
	<john.fastabend@gmail.com>, <andrii@kernel.org>,
	<martin.lau@linux.dev>, <eddyz87@gmail.com>, <song@kernel.org>,
	<yonghong.song@linux.dev>, <jolsa@kernel.org>, <tglx@kernel.org>,
	<bp@alien8.de>, <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	<hpa@zytor.com>, <shuah@kernel.org>, <mingo@redhat.com>,
	<andreyknvl@gmail.com>, <emil@etsalapatis.com>,
	<ihor.solodrai@linux.dev>, <laoar.shao@gmail.com>
Cc: <ebpf@linuxfoundation.org>, <bastien.curutchet@bootlin.com>,
	<thomas.petazzoni@bootlin.com>, <bpf@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
	<martin.lau@kernel.org>, <clm@meta.com>
Subject: Re: [PATCH bpf-next v7 1/9] bpf: mark instructions accessing program stack
Date: Mon, 24 Aug 2026 00:33:44 +0200	[thread overview]
Message-ID: <DKWOIW8NUFZA.1QPBXZJY5YYOL@gmail.com> (raw)
In-Reply-To: <f6a88fe55d543f5fe2a6d9e856acb4cf1b87b8210de58459df1272c8a456d926@mail.kernel.org>

On Sat Aug 22, 2026 at 1:24 AM CEST, bot+bpf-ci wrote:
>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>> index 004b06785521..412a13a664fa 100644
>> --- a/include/linux/bpf_verifier.h
>> +++ b/include/linux/bpf_verifier.h
>> @@ -725,6 +725,8 @@ struct bpf_insn_aux_data {
>>  	u16 const_reg_map_mask;
>>  	u16 const_reg_subprog_mask;
>>  	u32 const_reg_vals[10];
>> +	/* instruction can access non-stack memory */
>> +	bool non_stack_access;
>>  };
>
> [ ... ]
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index e036ae20bf6b..040af75d9550 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -3272,6 +3272,11 @@ static void mark_indirect_target(struct bpf_verifier_env *env, int idx)
>>  	env->insn_aux_data[idx].indirect_target = true;
>>  }
>>
>> +static void mark_non_stack_access(struct bpf_verifier_env *env, int idx)
>> +{
>> +	env->insn_aux_data[idx].non_stack_access = true;
>> +}
>> +
>
> [ ... ]
>
>> @@ -6654,6 +6659,10 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, struct b
>>  				clear_scalar_id(&regs[value_regno]);
>>  		}
>>  	}
>> +
>> +	if (!err && reg->type != PTR_TO_STACK)
>> +		mark_non_stack_access(env, insn_idx);
>> +
>>  	return err;
>>  }
>
> Does this test read the correct register type? For a load instruction where
> dst_reg == src_reg (e.g., rX = *(u64 *)(rX + off)), check_mem_access()
> receives reg = &regs[src_reg] and value_regno = dst_reg, so reg points to
> the same slot that gets overwritten by the load.
>
> When the pointer is PTR_TO_STACK, check_stack_read() runs:
>
> check_stack_read_fixed_off() {
>     state->regs[dst_regno] = *reg;  /* or mark_reg_stack_read() */
> }
>
> By the time execution reaches the new test, reg->type is the loaded value's
> type (typically SCALAR_VALUE), not PTR_TO_STACK. The condition evaluates to
> true and marks a stack-only access as non-stack.
>
> Both check_load_mem() and check_store_reg() snapshot the pointer type before
> calling check_mem_access():
>
>     /* verifier.c check_load_mem */
>     src_reg_type = regs[insn->src_reg].type;
>     err = check_mem_access(env, env->insn_idx, ...);
>
>     /* verifier.c check_store_reg */
>     dst_reg_type = regs[insn->dst_reg].type;
>     err = check_mem_access(env, env->insn_idx, ...);
>
> Could check_mem_access() snapshot reg->type at entry and test that snapshot
> instead?

This one also looks like a real bug, we should probably save the type before the
call as suggested and done elsewhere.

>
>
> ---
> 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/32534828209


  reply	other threads:[~2026-08-23 22:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 22:39 [PATCH bpf-next v7 0/9] bpf: add support for KASAN checks in JITed programs Alexis Lothoré (eBPF Foundation)
2026-08-21 22:39 ` [PATCH bpf-next v7 1/9] bpf: mark instructions accessing program stack Alexis Lothoré (eBPF Foundation)
2026-08-21 22:54   ` sashiko-bot
2026-08-21 23:24   ` bot+bpf-ci
2026-08-23 22:33     ` Kumar Kartikeya Dwivedi [this message]
2026-08-21 22:39 ` [PATCH bpf-next v7 2/9] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs Alexis Lothoré (eBPF Foundation)
2026-08-21 22:39 ` [PATCH bpf-next v7 3/9] bpf, x86: refactor BPF_ST management in do_jit Alexis Lothoré (eBPF Foundation)
2026-08-21 22:39 ` [PATCH bpf-next v7 4/9] bpf, x86: emit KASAN checks in x86 JITed programs Alexis Lothoré (eBPF Foundation)
2026-08-21 23:24   ` bot+bpf-ci
2026-08-21 23:33   ` sashiko-bot
2026-08-23 22:30     ` Kumar Kartikeya Dwivedi
2026-08-21 22:39 ` [PATCH bpf-next v7 5/9] bpf, x86: enable KASAN for JITed programs on x86 Alexis Lothoré (eBPF Foundation)
2026-08-21 22:55   ` sashiko-bot
2026-08-21 22:39 ` [PATCH bpf-next v7 6/9] selftests/bpf: make cmdline_contains stricter Alexis Lothoré (eBPF Foundation)
2026-08-21 22:39 ` [PATCH bpf-next v7 7/9] selftests/bpf: add helpers for KASAN in JIT testing Alexis Lothoré (eBPF Foundation)
2026-08-21 22:39 ` [PATCH bpf-next v7 8/9] selftests/bpf: move bpf_jit_harden helper into testing_helpers Alexis Lothoré (eBPF Foundation)
2026-08-21 23:13   ` bot+bpf-ci
2026-08-21 22:39 ` [PATCH bpf-next v7 9/9] selftests/bpf: add tests to validate KASAN on JIT programs Alexis Lothoré (eBPF Foundation)
2026-08-21 23:36   ` bot+bpf-ci
2026-08-23 22:40   ` Kumar Kartikeya Dwivedi
2026-08-23 22:53     ` Kumar Kartikeya Dwivedi
2026-08-23 22:53 ` [PATCH bpf-next v7 0/9] bpf: add support for KASAN checks in JITed programs Kumar Kartikeya Dwivedi

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=DKWOIW8NUFZA.1QPBXZJY5YYOL@gmail.com \
    --to=memxor@gmail.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=andreyknvl@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bastien.curutchet@bootlin.com \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=clm@meta.com \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=ebpf@linuxfoundation.org \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=hpa@zytor.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mingo@redhat.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=tglx@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=x86@kernel.org \
    --cc=yonghong.song@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.