CVE-2022-48921

What it actually does

Race condition between copy_process() and set_one_prio() allows a newly forked task to reach reweight_entity() with a null cfs_rq pointer before sched_post_fork() has initialized it, resulting in a null pointer dereference in the CFS scheduler.

Why it matters to the business

Local users on affected Linux kernels can trigger kernel crashes leading to denial of service; systems running multi-threaded workloads or containers face elevated risk of unexpected reboots and service disruption.

How an attack unfolds

An attacker with local access spawns a process that rapidly creates threads while concurrently issuing setpriority(PRIO_PGRP) calls on the thread group; the timing window created by the delayed cfs_rq assignment in sched_post_fork() causes the null dereference inside reweight_entity().

How to fix it

Upgrade the Linux kernel to a version containing commit 8bb7eca972ad531c9b149c0a51ab43a417385813 or later; rebuild and reboot with the patched kernel; where immediate patching is not possible, restrict untrusted local users from creating threads or calling setpriority on process groups.

How to confirm the fix worked

Verify the running kernel contains commit 8bb7eca972ad531c9b149c0a51ab43a417385813; attempt to reproduce the original syzbot reproducer under the patched kernel and confirm absence of the null dereference; review kernel build logs for the fix patch application.

Typical attack path

1. Spawn a process that forks many threads in quick succession
2. Issue setpriority(PRIO_PGRP, 0, -20) from another thread within the same group before sched_post_fork() completes for the new tasks
3. Trigger the race repeatedly until the null pointer dereference occurs in reweight_entity()
4. Observe kernel panic or oops leading to system instability or reboot

How to detect it

Search kernel logs for oops or panic messages referencing reweight_entity and null pointer dereference; inspect audit logs or process creation events for rapid sequences of clone/fork followed by setpriority calls on the same thread group; correlate with any user-space crash reports or container restarts.

What your security team should do

• Prioritize kernel updates on all multi-user and container-hosting systems within the next maintenance window
• Monitor upstream stable kernel releases for backports of 8bb7eca972ad531c9b149c0a51ab43a417385813
• Apply least-privilege controls to limit untrusted code from performing rapid thread creation and priority adjustments
• Test the patched kernel in staging environments before broad deployment