From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Feng Yang <yangfeng59949@163.com>,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, eddyz87@gmail.com, memxor@gmail.com,
song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
john.fastabend@gmail.com, kpsingh@kernel.org,
mattbobrowski@google.com
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf] bpf: Fix Null-Pointer Dereference in kernel_clone() via BPF fmod_ret on security_task_alloc
Date: Wed, 8 Apr 2026 20:16:45 +0800 [thread overview]
Message-ID: <409f3694-a054-4288-acd9-7900cc8f8620@linux.dev> (raw)
In-Reply-To: <20260408094816.228322-1-yangfeng59949@163.com>
On 4/8/26 5:48 PM, Feng Yang wrote:
> From: Feng Yang <yangfeng@kylinos.cn>
[...]
>
> diff --git a/include/linux/bpf_lsm.h b/include/linux/bpf_lsm.h
> index 643809cc78c3..434ae335b188 100644
> --- a/include/linux/bpf_lsm.h
> +++ b/include/linux/bpf_lsm.h
> @@ -48,6 +48,8 @@ void bpf_lsm_find_cgroup_shim(const struct bpf_prog *prog, bpf_func_t *bpf_func)
>
> int bpf_lsm_get_retval_range(const struct bpf_prog *prog,
> struct bpf_retval_range *range);
> +void bpf_security_get_retval_range(const struct bpf_prog *prog,
> + struct bpf_retval_range *range);
> int bpf_set_dentry_xattr_locked(struct dentry *dentry, const char *name__str,
> const struct bpf_dynptr *value_p, int flags);
> int bpf_remove_dentry_xattr_locked(struct dentry *dentry, const char *name__str);
> @@ -91,6 +93,12 @@ static inline int bpf_lsm_get_retval_range(const struct bpf_prog *prog,
> {
> return -EOPNOTSUPP;
> }
> +
> +static inline void bpf_security_get_retval_range(const struct bpf_prog *prog,
> + struct bpf_retval_range *range)
> +{
> +}
> +
> static inline int bpf_set_dentry_xattr_locked(struct dentry *dentry, const char *name__str,
> const struct bpf_dynptr *value_p, int flags)
> {
> diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
> index c5c925f00202..537af87b3d5d 100644
> --- a/kernel/bpf/bpf_lsm.c
> +++ b/kernel/bpf/bpf_lsm.c
> @@ -448,3 +448,29 @@ int bpf_lsm_get_retval_range(const struct bpf_prog *prog,
> }
> return 0;
> }
> +
> +/* hooks return 0 or 1 */
> +BTF_SET_START(bool_security_hooks)
> +#ifdef CONFIG_SECURITY_NETWORK_XFRM
> +BTF_ID(func, security_xfrm_state_pol_flow_match)
> +#endif
> +#ifdef CONFIG_AUDIT
> +BTF_ID(func, security_audit_rule_known)
> +#endif
> +BTF_ID(func, security_inode_xattr_skipcap)
> +BTF_SET_END(bool_security_hooks)
> +
> +/* Similar to bpf_lsm_get_retval_range,
> + * ensure that the return values of fmod_ret are valid.
> + */
> +void bpf_security_get_retval_range(const struct bpf_prog *prog,
> + struct bpf_retval_range *retval_range)
> +{
> + if (btf_id_set_contains(&bool_security_hooks, prog->aux->attach_btf_id)) {
> + retval_range->minval = 0;
> + retval_range->maxval = 1;
> + } else {
> + retval_range->minval = -MAX_ERRNO;
> + retval_range->maxval = 0;
> + }
> +}
> 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.
> 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
next prev parent reply other threads:[~2026-04-08 12:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 9:48 [PATCH bpf] bpf: Fix Null-Pointer Dereference in kernel_clone() via BPF fmod_ret on security_task_alloc Feng Yang
2026-04-08 11:53 ` Jiri Olsa
2026-04-09 10:24 ` Feng Yang
2026-04-08 12:16 ` Jiayuan Chen [this message]
2026-04-09 10:25 ` Feng Yang
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=409f3694-a054-4288-acd9-7900cc8f8620@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mattbobrowski@google.com \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=yangfeng59949@163.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox