CVE-2026-52980

Source
https://cve.org/CVERecord?id=CVE-2026-52980
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-52980.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-52980
Downstream
Published
2026-06-24T16:28:56.457Z
Modified
2026-07-08T08:13:44.921536835Z
Summary
sched/fair: Clear rel_deadline when initializing forked entities
Details

In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Clear rel_deadline when initializing forked entities

A yield-triggered crash can happen when a newly forked schedentity enters the fair class with se->reldeadline unexpectedly set.

The failing sequence is:

  1. A task is forked while se->rel_deadline is still set.
  2. _schedfork() initializes vruntime, vlag and other schedentity state, but does not clear reldeadline.
  3. On the first enqueue, enqueueentity() calls placeentity().
  4. Because se->reldeadline is set, placeentity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime.
  5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline.
  6. If the task later calls schedyield(), yieldtask_fair() advances se->vruntime to se->deadline.
  7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight.
  8. This corrupts cfsrq->sumwvruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. picknext_entity() may then return NULL unexpectedly, leading to a later NULL dereference.

A captured trace shows the effect clearly. Before yield, the entity's vruntime was around:

9834017729983308

After yieldtaskfair() executed:

se->vruntime = se->deadline

the vruntime jumped to:

19668035460670230

and the deadline was later advanced further to:

19668035463470230

This shows that the deadline had already become abnormally large before yieldtaskfair() copied it into vruntime.

reldeadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked schedentity should not inherit or retain this state. Clear se->rel_deadline in __schedfork(), together with the other schedentity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/52xxx/CVE-2026-52980.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
82e9d0456e06cebe2c89f3c73cdbc9e3805e9437
Fixed
c71bf35caba12bfd9bc23e32b0bcd9e02d1cf1ac
Fixed
f3c16e1f4a314a20717ab90a41885f8111a242ab
Fixed
8f4a16200785f49cf02c5b71bdfe7a9dab63f23a
Fixed
3da56dc063cd77b9c0b40add930767fab4e389f3

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-52980.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.12.0
Fixed
6.12.91
Type
ECOSYSTEM
Events
Introduced
6.13.0
Fixed
6.18.33
Type
ECOSYSTEM
Events
Introduced
6.19.0
Fixed
7.0.10

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-52980.json"