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

[sashiko-bot@kernel.org]

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?

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()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918052906.12226-1-memxor@gmail.com?part=3