CVE-2022-48671

What it actually does

Missing cpus_read_lock() acquisition in cgroup_attach_task_all() allows percpu_rwsem_assert_held failure during cpuset_attach when concurrent CPU hotplug occurs.

Why it matters to the business

Linux kernel instability or assertion warnings in containerized and multi-CPU environments can disrupt workloads that rely on cgroups, though exploitation risk remains low.

How an attack unfolds

A local attacker performs concurrent cgroup task attachments while triggering CPU hotplug events, hitting the missing lock that was overlooked in the prior deadlock fix.

How to fix it

Upgrade the Linux kernel to a version containing commit 321488cfac7d0eb6d97de467015ff754f85813ff or equivalent fixed release such as 5.4.215.

How to confirm the fix worked

Confirm the running kernel version meets or exceeds the fixed release and inspect cgroup.c to verify cpus_read_lock() surrounds the cgroup_attach_task_all call site.

Typical attack path

1. Gain local code execution on the target host
2. Issue cgroup attachment operations via cgroupfs or related syscalls
3. Simultaneously trigger CPU online/offline events
4. Trigger the cpuset_attach path without the required read lock

How to detect it

Review kernel logs and dmesg for percpu_rwsem_assert_held warnings mentioning cpuset_attach or cgroup_attach_task_all.

• percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at cpuset_attach
• syzbot is hitting percpu_rwsem_assert_held warning at cpuset_attach

What your security team should do

• Prioritize kernel upgrades on all affected Linux hosts
• Monitor kernel logs for cpuset_attach or cpu_hotplug_lock warnings
• Validate the patch in non-production environments before broad rollout