CVE-2026-52980
sched/fair: Clear rel_deadline when initializing forked entities
Description
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 is forked while se->rel_deadline is still set. 2. __sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline. 3. On the first enqueue, enqueue_entity() calls place_entity(). 4. 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. 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 sched_yield(), yield_task_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 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.
INFO
Published Date :
June 24, 2026, 5:17 p.m.
Last Modified :
July 14, 2026, 4:51 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | MEDIUM | [email protected] |
Solution
- Update the Linux kernel to a patched version.
- Ensure sched_entity state is properly cleared on fork.
- Verify rel_deadline is not inherited by forked entities.
- Prevent unexpected NULL dereferences during scheduling.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-52980.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-52980 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-52980
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-52980 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-52980 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
Initial Analysis by [email protected]
Jul. 14, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Added CWE CWE-476 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.13 up to (excluding) 6.18.33 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.19 up to (excluding) 7.0.10 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.12 up to (excluding) 6.12.91 Added Reference Type kernel.org: https://git.kernel.org/stable/c/3da56dc063cd77b9c0b40add930767fab4e389f3 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/8f4a16200785f49cf02c5b71bdfe7a9dab63f23a Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/c71bf35caba12bfd9bc23e32b0bcd9e02d1cf1ac Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/f3c16e1f4a314a20717ab90a41885f8111a242ab Types: Patch -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jun. 24, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '82e9d0456e06cebe2c89f3c73cdbc9e3805e9437', 'lessThan': 'c71bf35caba12bfd9bc23e32b0bcd9e02d1cf1ac', 'versionType': 'git'}, {'status': 'affected', 'version': '82e9d0456e06cebe2c89f3c73cdbc9e3805e9437', 'lessThan': 'f3c16e1f4a314a20717ab90a41885f8111a242ab', 'versionType': 'git'}, {'status': 'affected', 'version': '82e9d0456e06cebe2c89f3c73cdbc9e3805e9437', 'lessThan': '8f4a16200785f49cf02c5b71bdfe7a9dab63f23a', 'versionType': 'git'}, {'status': 'affected', 'version': '82e9d0456e06cebe2c89f3c73cdbc9e3805e9437', 'lessThan': '3da56dc063cd77b9c0b40add930767fab4e389f3', 'versionType': 'git'}], 'programFiles': ['kernel/sched/core.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '6.12'}, {'status': 'unaffected', 'version': '0', 'lessThan': '6.12', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '6.12.91', 'versionType': 'semver', 'lessThanOrEqual': '6.12.*'}, {'status': 'unaffected', 'version': '6.18.33', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '7.0.10', 'versionType': 'semver', 'lessThanOrEqual': '7.0.*'}, {'status': 'unaffected', 'version': '7.1', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['kernel/sched/core.c'], 'defaultStatus': 'affected'}] Added Description 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 is forked while se->rel_deadline is still set. 2. __sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline. 3. On the first enqueue, enqueue_entity() calls place_entity(). 4. 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. 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 sched_yield(), yield_task_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 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. Added Reference https://git.kernel.org/stable/c/3da56dc063cd77b9c0b40add930767fab4e389f3 Added Reference https://git.kernel.org/stable/c/8f4a16200785f49cf02c5b71bdfe7a9dab63f23a Added Reference https://git.kernel.org/stable/c/c71bf35caba12bfd9bc23e32b0bcd9e02d1cf1ac Added Reference https://git.kernel.org/stable/c/f3c16e1f4a314a20717ab90a41885f8111a242ab