CVE-2024-43853

What it actually does

Use-after-free in proc_cpuset_show() when a cgroup v1 cpuset root is rebound to the default root during umount while a concurrent read holds a reference to the css without protecting the cgroup pointer, allowing cgroup_root to be kfree_rcu'd underneath cgroup_path_ns_locked.

Why it matters to the business

Local denial-of-service on Linux systems that use cgroup v1 cpuset mounts; repeated triggering can crash the kernel and disrupt workloads or containers relying on cpuset accounting, with high prevalence across 28k+ downstream dependents increasing exposure surface.

How an attack unfolds

An attacker with local access repeatedly mounts and unmounts a cpuset cgroup v1 hierarchy while concurrently reading /proc/<pid>/cpuset; the race window created by delayed cgroup_lock acquisition frees the cgroup_root structure after the css reference is obtained but before the path lookup completes, triggering UAF. No named threat actors are tied to this specific flaw despite broad Linux kernel targeting campaigns.

How to fix it

Upgrade the Linux kernel to a version containing commit 27d6dbdc6485d68075a0ebf8544d6425c1ed84bb or later; apply the rcu_read_lock change in proc_cpuset_show() and ensure task_css is used under css_set_lock. Reboot after patching. No KEV deadline applies.

How to confirm the fix worked

Verify the running kernel contains commit 27d6dbdc6485d68075a0ebf8544d6425c1ed84bb; attempt to reproduce the original syzkaller race conditions and confirm absence of UAF; inspect /proc/<pid>/cpuset reads under concurrent v1 cpuset mount/umount stress.

Typical attack path

1. Obtain local user access on a Linux host using cgroup v1 cpusets
2. Repeatedly mount -t cgroup -o cpuset and unmount /sys/fs/cgroup/cpuset
3. Concurrently and repeatedly read /proc/<target-pid>/cpuset
4. Trigger the race that frees cgroup_root while proc_cpuset_show holds a stale pointer
5. Cause kernel panic or memory corruption via UAF

How to detect it

Search kernel logs for UAF reports or slab corruption near cgroup_path_ns and proc_cpuset_show; look for repeated mount/umount activity on cpuset hierarchies correlated with high-frequency /proc reads; no public exploitation IOCs are known.

What your security team should do

• Prioritize kernel updates on all systems exposing cpuset cgroups or /proc mounts
• Monitor for local privilege-escalation attempts that could chain this DoS into further impact
• Restrict unprivileged mount/umount capabilities via SELinux/AppArmor or user namespaces where feasible
• Review container runtime configurations that rely on cgroup v1 cpusets for additional hardening