CVE-2026-52980

NONECVSS 0.0
0.0
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No confirmed exploitation signals yet
CISA-KEV: Not listedEPSS: 0%CVSS: —Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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 sched_entity enters the fair class with se->rel_deadline unexpectedly set.

The failing sequence is:

  • A task is forked while se->rel_deadline is still set.
  • __sched_fork() initializes vruntime, vlag and other sched_entity
state, but does not clear rel_deadline.
  • On the first enqueue, enqueue_entity() calls place_entity().
  • Because se->rel_deadline is set, place_entity() treats se->deadline
as a relative deadline and converts it to an absolute deadline by adding the current vruntime.
  • 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.
  • If the task later calls sched_yield(), yield_task_fair() advances
se->vruntime to se->deadline.
  • The inflated vruntime is then used by the following enqueue path,
where the vruntime-derived key can overflow when multiplied by the entity weight.
  • This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility
calculation, and can eventually make all entities appear ineligible. pick_next_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 yield_task_fair() 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 yield_task_fair() copied it into vruntime.

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

CVSS v3
—
EG Score
0.0(none)
EPSS
6.4%
KEV
Not listed

Published

June 24, 2026

Last Modified

June 24, 2026

References (4)

Vendor Advisories for CVE-2026-52980(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 13× in last 7d / 23× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-06 19:55 UTCGHSA enrichment
  2. 2026-07-06 19:52 UTCGHSA enrichment
  3. 2026-07-06 16:27 UTCEPSS rescore
  4. 2026-07-06 16:27 UTCEPSS rescore
  5. 2026-07-06 02:23 UTCEPSS rescore
  6. 2026-07-06 02:23 UTCEPSS rescore
  7. 2026-07-05 02:31 UTCEPSS rescore
  8. 2026-07-05 02:30 UTCEPSS rescore
  9. 2026-07-04 06:31 UTCEPSS rescore
  10. 2026-07-03 19:29 UTCGHSA enrichment
  11. 2026-07-01 15:07 UTCEPSS rescore
  12. 2026-06-30 23:22 UTCEPSS rescore
  13. 2026-06-30 19:08 UTCGHSA enrichment
  14. 2026-06-29 14:06 UTCEPSS rescore
  15. 2026-06-29 14:06 UTCEPSS rescore
  16. 2026-06-28 04:56 UTCEPSS rescore
  17. 2026-06-28 04:56 UTCEPSS rescore
  18. 2026-06-27 18:47 UTCEG score recompute
  19. 2026-06-27 18:47 UTCGHSA enrichment
  20. 2026-06-27 03:08 UTCEPSS rescore
  21. 2026-06-25 13:49 UTCEPSS rescore
  22. 2026-06-24 18:26 UTCEG score recompute
  23. 2026-06-24 18:02 UTCNVD updatefirst tracked

Frequently asked(4)

What is CVE-2026-52980?
CVE-2026-52980 is a none vulnerability published on June 24, 2026. 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 sched_entity enters the fair class with se->rel_deadline unexpectedly set. The failing sequence is: 1. A task…
When was CVE-2026-52980 disclosed?
CVE-2026-52980 was first published in the National Vulnerability Database on June 24, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-52980 actively exploited?
CVE-2026-52980 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 6.4% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
How do I remediate CVE-2026-52980?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-52980, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-52980

Explore →

Is Your Infrastructure Affected by CVE-2026-52980?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.

Start Free Scan →Browse All CVEs