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

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

[Pu Lehui]

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 a link update 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>
Acked-by: Leon Hwang <leon.hwang@linux.dev>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
v6:
- Update inconsistent commit msg.
- Add Acked-by tag by Leon.

v5: https://lore.kernel.org/bpf/20260805035342.349421-1-pulehui@huaweicloud.com
- 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 v6] bpf, cgroup: Fix storage null-ptr-deref after replacing prog

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 4400 bytes --]

> 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.

Is the description "inherits an uninit storage" precise?

Looking at the code, the storage array is not uninitialized in the C
sense. When prog A (which uses no cgroup storage) is attached, both
pl->storage[] and item->cgroup_storage[] are explicitly initialized to
NULL. When compute_effective_progs() copies pl->storage into
item->cgroup_storage via bpf_cgroup_storages_assign(), it copies the
all-NULL array.

So prog B inherits the previous prog's storage array, which is NULL for
the map prog B needs. The distinction also explains the broader case:
if prog A used a different storage map, the inherited pointer would be
non-NULL but belong to the wrong map, leading to a cross-map
out-of-bounds read rather than just a NULL dereference.

Would "the new prog inherits the previous prog's storage array (NULL for
the map the new prog needs)" be more accurate?


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

Does the commit message capture the full scope of what this fixes?

The message describes only the NULL case from the syzkaller reproducer.
However, cgroup_bpf_storages_compatible() compares map pointers per
stype, so it also rejects the case where prog A uses map M1 and prog B
uses map M2 for the same storage type.

In that case, item->cgroup_storage[stype] would point to M1's live
storage, but prog B's bpf_get_local_storage() would return M1's buffer
while the verifier sized accesses against M2->value_size. Since
bpf_cgroup_storage_calculate_size() sizes the buffer from the owning
map, this would be a cross-map data disclosure or out-of-bounds read,
not just a NULL dereference.

Would it be clearer to mention that the fix also blocks the wrong-map
case to prevent cross-map access?


The commit message opens with "Syzkaller reported" but includes no
Reported-by or Closes tags. Two public syzbot reports match this issue:

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

Both are titled "general protection fault in bpf_get_local_storage" with
KASAN null-ptr-deref at the same location. The reproducers match the
3-step scenario call-for-call.

Should these include the standard syzbot attribution tags so the reports
get auto-closed?

Also, BPF_LINK_UPDATE calls that previously returned 0 now return
-EINVAL. This is an intentional trade-off for a less risky fix, but the
commit message does not mention the uAPI behaviour change. Might that be
worth noting?


> 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
> @@ -1018,6 +1018,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
> @@ -1056,6 +1070,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);


---
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/31172497940

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

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko <andrii@kernel.org>:

On Fri,  7 Aug 2026 10:44:03 +0000 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - [bpf,v6] bpf, cgroup: Fix storage null-ptr-deref after replacing prog
    https://git.kernel.org/bpf/bpf-next/c/3f562c537e9e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html