Re: [PATCH bpf] bpf: Fix Null-Pointer Dereference in kernel_clone() via BPF fmod_ret on security_task_alloc

[Feng Yang <yangfeng59949@163.com>]

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