[v5] bpf, cgroup: Fix storage null-ptr-deref after replacing prog

[PATCH bpf v5] bpf, cgroup: Fix storage null-ptr-deref after replacing prog

Posted by Pu Lehui 1 month, 4 weeks ago

From: Pu Lehui <pulehui@huawei.com>

Syzkaller reported a storage null-ptr-deref issue after replacing prog.
This occurs in the following scenario:
1. prog A, an empty prog, is attached to a cgrp.
2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the
   bpf_get_local_storage helper.
3. link_update is called to replace prog A with prog B.

The reason is that __cgroup_bpf_replace fails to alloc and assign the
required cgrp storage for the incoming replacement prog. Consequently,
the new prog inherits an uninit storage, leading to null-ptr-deref panic
when kick the new prog.

Fix this by rejecting link update with -EPERM if new_prog's cgroup
storage is incompatible with link->prog.

Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link")
Reviewed-by: Amery Hung <ameryhung@gmail.com>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
v5:
- Reject link update if new_prog's storage is incompatible with link->prog. (Andrii)

v4: https://lore.kernel.org/bpf/20260728133058.2858367-1-pulehui@huaweicloud.com
- Extract the fix for __cgroup_bpf_attach() into a standalone patch [0].
- Add Reviewed-by tag by Amery.
- Separate from patchset [1]. (Andrii)

Link: https://lore.kernel.org/bpf/20260728132336.2857800-1-pulehui@huaweicloud.com [0]
Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [1]

v3: https://lore.kernel.org/bpf/20260720134547.1289964-5-pulehui@huaweicloud.com
- Include the storage and flags rollbacks to patch4 for sake of code rigor,
  as it's hard to make update_effective_progs fail in __cgroup_bpf_attach.

v2: https://lore.kernel.org/bpf/20260717073343.958862-1-pulehui@huaweicloud.com
- Fix invalid access for in-place update when storage changed. (Sashiko)

v1: https://lore.kernel.org/bpf/20260714014659.401063-1-pulehui@huaweicloud.com

 kernel/bpf/cgroup.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 57fd1d784e44..31c63ff276fa 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -1026,6 +1026,20 @@ static void replace_effective_prog(struct cgroup *cgrp,
 	}
 }
 
+static bool cgroup_bpf_storages_compatible(struct bpf_prog *old_prog,
+					   struct bpf_prog *new_prog)
+{
+	enum bpf_cgroup_storage_type stype;
+
+	for_each_cgroup_storage_type(stype) {
+		if (old_prog->aux->cgroup_storage[stype] !=
+		    new_prog->aux->cgroup_storage[stype])
+			return false;
+	}
+
+	return true;
+}
+
 /**
  * __cgroup_bpf_replace() - Replace link's program and propagate the change
  *                          to descendants
@@ -1064,6 +1078,9 @@ static int __cgroup_bpf_replace(struct cgroup *cgrp,
 	if (!found)
 		return -ENOENT;
 
+	if (!cgroup_bpf_storages_compatible(link->link.prog, new_prog))
+		return -EINVAL;
+
 	cgrp->bpf.revisions[atype] += 1;
 	old_prog = xchg(&link->link.prog, new_prog);
 	replace_effective_prog(cgrp, atype, pl);
-- 
2.34.1

Re: [PATCH bpf v5] bpf, cgroup: Fix storage null-ptr-deref after replacing prog

Posted by bot+bpf-ci@kernel.org 1 month, 3 weeks ago

> commit c953408b860e553dc6831c7b95e870d0d1ef878d
> Author: Pu Lehui <pulehui@huawei.com>
> Date:   Wed Aug 5 03:53:42 2026 +0000
>
>     bpf, cgroup: Fix storage null-ptr-deref after replacing prog
>
>     Syzkaller reported a storage null-ptr-deref issue after replacing prog.
>     This occurs in the following scenario:
>     1. prog A, an empty prog, is attached to a cgrp.
>     2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the
>        bpf_get_local_storage helper.
>     3. link_update is called to replace prog A with prog B.
>
>     The reason is that __cgroup_bpf_replace fails to alloc and assign the
>     required cgrp storage for the incoming replacement prog. Consequently,
>     the new prog inherits an uninit storage, leading to null-ptr-deref panic
>     when kick the new prog.
>
>     Fix this by rejecting link update with -EPERM if new_prog's cgroup
>     storage is incompatible with link->prog.
>
>     Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link")
>     Reviewed-by: Amery Hung <ameryhung@gmail.com>
>     Signed-off-by: Pu Lehui <pulehui@huawei.com>

The commit message says "Syzkaller reported" but there's no Reported-by
or Closes tag. Two public syzbot reports exist for this exact issue:

  - syzbot+4fe468a3f7fac86ea2c9@syzkaller.appspotmail.com
  - syzbot+e6e8f6618a2d4b35e4e0@syzkaller.appspotmail.com

Both reports contain KASAN null-ptr-deref traces at
____bpf_get_local_storage, and the public C reproducer matches the
described 3-step scenario exactly.

Should the commit include Reported-by and Closes tags so syzbot can
auto-close these reports?

> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 4355ccb78a9c..5cc9b2d92fd5 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/30973728779