CVE-2026-43323

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix zero_vruntime tracking fix<br /> <br /> John reported that stress-ng-yield could make his machine unhappy and<br /> managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix<br /> zero_vruntime tracking").<br /> <br /> The combination of yield and that commit was specific enough to<br /> hypothesize the following scenario:<br /> <br /> Suppose we have 2 runnable tasks, both doing yield. Then one will be<br /> eligible and one will not be, because the average position must be in<br /> between these two entities.<br /> <br /> Therefore, the runnable task will be eligible, and be promoted a full<br /> slice (all the tasks do is yield after all). This causes it to jump over<br /> the other task and now the other task is eligible and current is no<br /> longer. So we schedule.<br /> <br /> Since we are runnable, there is no {de,en}queue. All we have is the<br /> __{en,de}queue_entity() from {put_prev,set_next}_task(). But per the<br /> fingered commit, those two no longer move zero_vruntime.<br /> <br /> All that moves zero_vruntime are tick and full {de,en}queue.<br /> <br /> This means, that if the two tasks playing leapfrog can reach the<br /> critical speed to reach the overflow point inside one tick&amp;#39;s worth of<br /> time, we&amp;#39;re up a creek.<br /> <br /> Additionally, when multiple cgroups are involved, there is no guarantee<br /> the tick will in fact hit every cgroup in a timely manner. Statistically<br /> speaking it will, but that same statistics does not rule out the<br /> possibility of one cgroup not getting a tick for a significant amount of<br /> time -- however unlikely.<br /> <br /> Therefore, just like with the yield() case, force an update at the end<br /> of every slice. This ensures the update is never more than a single<br /> slice behind and the whole thing is within 2 lag bounds as per the<br /> comment on entity_key().