Re: [PATCH bpf-next v4 3/8] bpf: Check read access for initialized writable memory arguments

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2026-09-18 at 05:50 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] bpf: MEM_WRITE without MEM_UNINIT enforces BPF_READ breaking output helpers
> --
> 
> commit aebadfb01a3b32540321fe2b60bcb6fb1c8673be
> Author: Eduard Zingerman <eddyz87@gmail.com>
> 
> bpf: Check read access for initialized writable memory arguments
> 
> This commit updates the BPF verifier to derive memory access types based on
> argument flags, correctly enforcing read access for writable memory arguments
> that are already initialized. The change addresses an issue where helper
> argument checking previously omitted read permission checks on map values. It
> adds a generic func_arg_access_type() helper to replace the kfunc-specific
> access overrides.
> 
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 1d5e4ee64fc00..21eb806b1351c 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -8886,6 +8886,15 @@ static int process_map_ptr_arg(struct bpf_verifier_env *env, struct bpf_reg_stat
> >  	return 0;
> >  }
> >  
> > +static enum bpf_access_type func_arg_access_type(enum bpf_arg_type arg_type)
> > +{
> > +	if (!(arg_type & MEM_WRITE))
> > +		return BPF_READ;
> > +	if (arg_type & MEM_UNINIT)
> > +		return BPF_WRITE;
> > +	return BPF_READ | BPF_WRITE;
> > +}
> 
> [Severity: Critical]
> Does this regression break pure output helpers that lack the MEM_UNINIT flag?
> 
> For example, bpf_snprintf() is defined as an output helper:
> 
> kernel/bpf/helpers.c:
> const struct bpf_func_proto bpf_snprintf_proto = {
>     ...
>     .arg1_type  = ARG_PTR_TO_MEM_OR_NULL | MEM_WRITE,
>     ...
> };
> 
> Because bpf_snprintf() does not guarantee full buffer initialization, it
> cannot be safely marked with MEM_UNINIT. However, with this change, the lack
> of MEM_UNINIT means func_arg_access_type() will return BPF_READ | BPF_WRITE
> instead of just BPF_WRITE.
> 
> Will this inadvertently force check_helper_mem_access() to reject valid
> write-only maps (BPF_F_WRONLY_PROG) when passed to such output helpers, causing
> valid BPF programs to fail verification?

I think it should be safe to relax MEM_UNINIT interpretation for priv
and not to require full buffer initialization. That would be only a
documentation change, as far as I understand. Then it would be fine to
put MEM_UNINIT for snprintf. For unpriv and MEM_UNINIT buffer we can
scratch the buffer as a combination of BPF_MISC (for previously filled parts) /
BPF_INVALID (for previously invalid parts) instead of requiring full initialization.
Kartikeya, could you please take a look if this requires any code changes?

> Additionally, for unprivileged programs lacking CAP_PERFMON, won't this
> erroneously enforce stack buffer pre-initialization by enforcing a read check
> requiring stack initialization in check_stack_range_initialized()?

But that's not an error. If the helper reads the memory, there is no
MEM_UNINIT annotation and we pass a pointer to uninitiated memory
buffer to the program, then such a program should be rejected.