From: Pu Lehui <pulehui@huawei.com>
To: Pu Lehui <pulehui@huaweicloud.com>, <bpf@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Yonghong Song <yonghong.song@linux.dev>,
Song Liu <song@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>
Subject: Re: [PATCH bpf] bpf, cgroup: Fix potential UAF in __cgroup_bpf_attach
Date: Wed, 29 Jul 2026 18:02:05 +0800 [thread overview]
Message-ID: <a528cfaf-42bf-41e8-be61-32693334a39c@huawei.com> (raw)
In-Reply-To: <20260728132336.2857800-1-pulehui@huaweicloud.com>
On 2026/7/28 21:23, Pu Lehui wrote:
> From: Pu Lehui <pulehui@huawei.com>
>
> When replacing an existing bpf_link in single-attach case in
> __cgroup_bpf_attach, old_prog is NULL while old_link holds the active
> link. If attachment fails midway (bpf_trampoline_link_cgroup_shim or
> update_effective_progs), the cleanup check `if (!old_prog)` wrongly
> treats the existing pl entry as newly allocated, calling kfree() and
> causing a UAF.
>
> Additionally, original flags and storage state are not restored on
> failure.
>
> Fix this by checking `!old_prog && !old_link` before freeing pl, and
> properly restoring all previous states on error.
Nack, sorry for the noise.
link attach only support BPF_F_ALLOW_MULTI mode, so it will not occur
UAF pl.
But there still remain an invalid storage access issue. I have been
mentioned and fix it in v2. Hope that will fix.
https://lore.kernel.org/bpf/20260729100208.3076769-1-pulehui@huaweicloud.com/T/#u
>
> Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
> ---
> kernel/bpf/cgroup.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index e2fa0ebeed83..e22e7dfe0022 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -811,10 +811,13 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp,
> {
> u32 saved_flags = (flags & (BPF_F_ALLOW_OVERRIDE | BPF_F_ALLOW_MULTI));
> struct bpf_prog *old_prog = NULL;
> + struct bpf_cgroup_link *old_link = NULL;
> struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {};
> struct bpf_cgroup_storage *new_storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {};
> + struct bpf_cgroup_storage *old_storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {};
> struct bpf_prog *new_prog = prog ? : link->link.prog;
> enum cgroup_bpf_attach_type atype;
> + u32 old_flags, old_pl_flags;
> struct bpf_prog_list *pl;
> struct hlist_head *progs;
> int err;
> @@ -865,6 +868,9 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp,
>
> if (pl) {
> old_prog = pl->prog;
> + old_link = pl->link;
> + old_pl_flags = pl->flags;
> + bpf_cgroup_storages_assign(old_storage, pl->storage);
> } else {
> pl = kmalloc_obj(*pl);
> if (!pl) {
> @@ -884,6 +890,7 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp,
> pl->link = link;
> pl->flags = flags;
> bpf_cgroup_storages_assign(pl->storage, storage);
> + old_flags = cgrp->bpf.flags[atype];
> cgrp->bpf.flags[atype] = saved_flags;
>
> if (type == BPF_LSM_CGROUP) {
> @@ -912,15 +919,18 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp,
> bpf_trampoline_unlink_cgroup_shim(new_prog);
>
> cleanup:
> - if (old_prog) {
> + if (old_prog || old_link) {
> pl->prog = old_prog;
> - pl->link = NULL;
> + pl->link = old_link;
> + pl->flags = old_pl_flags;
> + bpf_cgroup_storages_assign(pl->storage, old_storage);
> }
> bpf_cgroup_storages_free(new_storage);
> - if (!old_prog) {
> + if (!old_prog && !old_link) {
> hlist_del(&pl->node);
> kfree(pl);
> }
> + cgrp->bpf.flags[atype] = old_flags;
> return err;
> }
>
prev parent reply other threads:[~2026-07-29 10:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 13:23 Pu Lehui
2026-07-29 10:02 ` Pu Lehui [this message]
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=a528cfaf-42bf-41e8-be61-32693334a39c@huawei.com \
--to=pulehui@huawei.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=pulehui@huaweicloud.com \
--cc=song@kernel.org \
--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
all inboxes | Powered by JetHome®