CVE-2026-52980

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.

• CWE-476

• https://git.kernel.org/stable/c/3da56dc063cd77b9c0b40add930767fab4e389f3Patch
• https://git.kernel.org/stable/c/8f4a16200785f49cf02c5b71bdfe7a9dab63f23aPatch
• https://git.kernel.org/stable/c/c71bf35caba12bfd9bc23e32b0bcd9e02d1cf1acPatch
• https://git.kernel.org/stable/c/f3c16e1f4a314a20717ab90a41885f8111a242abPatch

Published

Jun 24, 2026

Last Modified

Jul 14, 2026

Status

Analyzed

• How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2026-52974In the Linux kernel, the following vulnerability has been re…7.5
• CVE-2026-52975In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-52976In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-52977In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52978In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52979In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52981In the Linux kernel, the following vulnerability has been re…7.5
• CVE-2026-52982In the Linux kernel, the following vulnerability has been re…9.8
• CVE-2026-52983In the Linux kernel, the following vulnerability has been re…7.5
• CVE-2026-52984In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52985In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52986In the Linux kernel, the following vulnerability has been re…9.8