CVE-2026-52980
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
sched/fair: rel_deadline wissen bij het initialiseren van gevorkte entiteiten
Een door opbrengst veroorzaakte crash kan optreden wanneer een nieuw gevorkte sched_entity
betreedt de beursklasse met se->rel_deadline onverwacht ingesteld. De falende volgorde is:
1. Een taak is gevorkte terwijl se->rel_deadline nog steeds is ingesteld. 2. __sched_fork() initialiseert vruntime, vlag en andere sched_entity
staat, maar maakt rel_deadline niet duidelijk. 3. Bij de eerste wachtrij roept enqueue_entity() place_entity() aan. 4. Omdat se->rel_deadline is ingesteld, behandelt place_entity() se->deadline
als een relatieve deadline en converteert deze naar een absolute deadline door
het toevoegen van de huidige vruntime. 5. De deadline van de gevorkte entiteit is echter geen geldige geërfde
relatieve deadline voor deze nieuwe planningsinstantie, dus de conversie
een abnormaal grote deadline oplevert. 6. Als de taak later sched_yield() aanroept, gaat yield_task_fair() vooruit
se->vruntime tot se->deadline. 7. De opgeblazen vruntime wordt vervolgens gebruikt door het volgende wachtrijpad,
waarbij de van vruntime afgeleide sleutel kan overlopen wanneer deze wordt vermenigvuldigd met de
gewicht van de entiteit. 8. Dit corrumpeert cfs_rq- >sum_w_vruntime, breekt EEVDF-geschiktheid
berekening en kan er uiteindelijk voor zorgen dat alle entiteiten niet in aanmerking komen. pick_next_entity() kan dan onverwacht NULL retourneren, wat leidt tot een
later NULL dereferentie. Een vastgelegd spoor toont het effect duidelijk. Vóór de opbrengst is de entiteit
vruntime was rond:
9834017729983308
Na yield_task_fair() uitgevoerd:
se->vruntime = se->deadline
de vruntime sprong naar:
19668035460670230
en de deadline werd later verder opgeschoven naar:
19668035463470230
Hieruit blijkt dat de deadline al eerder abnormaal groot was geworden
yield_task_fair() heeft het naar vruntime gekopieerd. rel_deadline is alleen zinvol als se->deadline echt een
relatieve deadline die nog moet worden geplaatst tegen vruntime. Een
vers gevorkte sched_entity mag deze status niet erven of behouden. Wis se->rel_deadline in __sched_fork(), samen met de andere
sched_entity runtime status, zodat de eerste wachtrij niet interpreteert
de deadline van de nieuwe entiteit als een verouderde relatieve deadline.
Origineel (Engels) tonen
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.