Linux kernel scheduler: two yielding tasks can overflow vruntime and destabilize the host

CVSS 5.5CVE-2026-43323Kernel, userspace & hypervisorcurated

Impact

After the earlier zero_vruntime tracking change, only a tick or a full enqueue/dequeue moved the scheduler's vruntime reference point. Two runnable tasks doing nothing but sched_yield() leapfrog each other fast enough to reach the vruntime overflow point inside a single tick, and with cgroups in play a given group may not get a timely tick at all. The reported symptom is a machine made unhappy by stress-ng-yield - a local, unprivileged availability attack on the scheduler itself. On a shared GPU node, any tenant pod can run this; the victims are the co-tenant training jobs on the same host, and recovering means rebooting a node you cannot drain cheaply. Affects kernels that carry the zero_vruntime tracking commit, not older stable series.

Who can reach it

Any local user or container that can run two threads - no privilege, no device access, no network. On a GPU cloud this means any tenant with a pod on the node.

What to do

Update to a stable kernel containing the forced zero_vruntime update at slice end and reboot the node; scheduler core changes are not hot-patchable in practice. If you are on a kernel that predates the zero_vruntime tracking commit, you are not affected and do not need the window.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-43323 https://git.kernel.org/stable/c/1319ea57529e131822bab56bf417c8edc2db9ae8

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.