Re: [PATCH bpf] bpf: Fix Null-Pointer Dereference in kernel_clone() via BPF fmod_ret on security_task_alloc
From: Feng Yang
Date: Thu Apr 09 2026 - 06:26:21 EST
On Wed, 8 Apr 2026 20:16:45 +0800 Jiayuan Chen wrote:
[...]
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 594260c1f382..3bfc67983e12 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -18413,8 +18413,10 @@ static bool return_retval_range(struct bpf_verifier_env *env, struct bpf_retval_
> > *range = retval_range(0, 0);
> > break;
> > case BPF_TRACE_RAW_TP:
> > - case BPF_MODIFY_RETURN:
> > return false;
> > + case BPF_MODIFY_RETURN:
> > + bpf_security_get_retval_range(env->prog, range);
> > + break;
>
> This is a breaking change. The verifier rejection log should be more
> descriptive
> so users can understand why their program is being rejected.
It should be easy to see from the existing error log that the return value does not meet the requirements:
At program exit the register R0 has smin=1 smax=1 should have been in [-4095, 0]
processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
>
> > case BPF_TRACE_ITER:
> > default:
> > break;
>
> Also, I think a whitelist approach would be better here.
> The known danger is specifically those security hooks whose return
> values get fed into ERR_PTR() by callers, such as:
> - security_task_alloc
> - security_inode_readlink
> - security_task_movememory
> - security_inode_follow_link
> - security_fs_context_submount
> - security_dentry_create_files_as
> - security_perf_event_alloc
> - security_inode_get_acl