CVE-2026-52980

What it actually does

This is a Linux kernel scheduler flaw in the Completely Fair Scheduler/EEVDF path. A newly forked sched_entity can retain a stale rel_deadline flag, causing the scheduler to treat an invalid inherited deadline as a relative deadline during first enqueue. That can inflate the entity's deadline and vruntime; after sched_yield(), the inflated value can corrupt scheduler accounting such as cfs_rq->sum_w_vruntime, break entity eligibility calculations, cause pick_next_entity() to return NULL unexpectedly, and ultimately trigger a kernel NULL pointer dereference or crash. The practical impact is local denial of service through kernel panic or system instability, assuming an attacker can run code that repeatedly forks and yields on an affected kernel.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems, interrupting workloads, containers, virtual machines, and services hosted on affected kernels. Because this is a kernel-level denial-of-service issue, the operational consequence can be full host outage rather than failure of a single application. Current public exploitation signals are low: EPSS is low, the issue is not listed in CISA KEV, and no mature public exploit is indicated in the provided data, but internet-scale prevalence depends on how broadly affected kernel versions are deployed across distributions and appliances.

How an attack unfolds

An attacker who can execute local code on an affected Linux system would attempt to create scheduler state that leaves rel_deadline set across a fork boundary. The attacker-controlled process forks a child task, causing __sched_fork() to initialize much of the child sched_entity state while failing to clear the stale rel_deadline flag. When the child is first enqueued, enqueue_entity() and place_entity() misinterpret the child deadline as a relative deadline and convert it into an abnormally large absolute deadline. The task then calls sched_yield(), causing yield_task_fair() to copy that inflated deadline into vruntime. Subsequent enqueue and eligibility calculations can overflow or corrupt scheduler runtime accounting, eventually making runnable entities appear ineligible. The scheduler may then fail to select a valid next entity and dereference NULL, crashing the kernel or making the host unstable.

How to fix it

Apply the Linux kernel update from the relevant distribution, appliance vendor, cloud image provider, or kernel maintainer that includes the fix to clear se->rel_deadline in __sched_fork(). No exact fixed package versions were provided in the input, so use vendor advisories and package changelogs to identify the corrected kernel build for each supported platform. After updating, reboot systems into the fixed kernel; merely installing kernel packages is insufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting untrusted local code execution, restricting shell access, constraining container workloads, applying resource controls to fork-heavy workloads, and prioritizing patching on multi-tenant, container-hosting, CI/CD, build, HPC, and shared-user Linux systems.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build containing the scheduler fix, not only that the package is installed. Validate with uname -a, package manager kernel version output, and vendor advisory mapping. Where source or debug symbols are available, confirm the __sched_fork() implementation clears rel_deadline along with other sched_entity runtime state. Review boot history to ensure the fixed kernel was loaded after patching. In test environments, run scheduler stress tests involving fork and sched_yield() patterns and confirm there are no kernel oops, panic, NULL pointer dereference, or scheduler eligibility anomalies in kernel logs.

Typical attack path

1. Gain the ability to execute local code on an affected Linux host, container host, or virtual machine.
2. Run a workload that repeatedly forks processes or threads to create new sched_entity instances.
3. Trigger scheduling behavior where a forked entity retains stale rel_deadline state.
4. Cause the forked task to enter the fair scheduler class and be enqueued, leading place_entity() to convert an invalid deadline into an inflated absolute deadline.
5. Call sched_yield() from the affected task so yield_task_fair() advances vruntime to the inflated deadline.
6. Repeat or sustain the pattern until scheduler accounting is corrupted and the kernel crashes or becomes unstable.

How to detect it

To determine whether exploitation or attempted exploitation already occurred, review kernel and system logs for crashes or oops traces involving the fair scheduler, EEVDF eligibility, fork, enqueue, or yield paths. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore artifacts, hypervisor reset records, and EDR telemetry for local processes generating unusual fork-and-yield behavior. Look for kernel NULL pointer dereferences, panic events, soft lockups, scheduler warnings, stack traces containing functions such as yield_task_fair, enqueue_entity, place_entity, pick_next_entity, __sched_fork, or references to sum_w_vruntime. Correlate crash timestamps with local user sessions, container workloads, CI jobs, batch jobs, or processes showing high rates of fork/clone and sched_yield activity. Absence of these artifacts does not prove non-exploitation, because a successful denial-of-service may leave only partial logs if the host crashes abruptly.

• NULL pointer dereference
• kernel NULL pointer dereference
• Kernel panic
• BUG: kernel NULL pointer dereference
• Oops:
• pick_next_entity
• yield_task_fair
• enqueue_entity
• place_entity
• __sched_fork
• sum_w_vruntime
• sched_yield
• rel_deadline
• se->rel_deadline
• cfs_rq->sum_w_vruntime
• EEVDF
• sched/fair

What your security team should do

• Inventory Linux systems and identify those running affected kernel branches or vendor builds.
• Prioritize patching shared, multi-tenant, container-host, CI/CD, build, research, and user-accessible Linux systems because local code execution can translate into host-level denial of service.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the active kernel version after reboot.
• Temporarily reduce risk on unpatched systems by limiting untrusted local execution, tightening container admission controls, and applying process/fork limits where operationally safe.
• Monitor kernel logs for scheduler-related crashes, NULL pointer dereferences, and repeated fork/yield stress patterns until patching is complete.
• Because EPSS is low, no KEV listing is present, and no mature public exploit is indicated, treat this as important reliability and local-abuse risk rather than currently confirmed widespread exploitation.