GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sched/deadline: WARN_ON reachable by a local task when a PI-boosted task is requeued

CVSS 5.5CVE-2024-56583Kernel, userspace & hypervisorcurated

Impact

An unprivileged local task can drive the deadline scheduler into a WARN_ON in setup_new_dl_entity() by having a priority-inheritance-boosted task re-enqueued with ENQUEUE_RESTORE, which happens on an affinity change during rt_spin_unlock. The result is a kernel warning and backtrace, not memory corruption or privilege gain. It matters on a GPU node only in two cases: the fleet boots with panic_on_warn, where any tenant process can take the whole node down and force an unplanned drain of long-running training jobs, or the node runs a PREEMPT_RT kernel where the reproducer in the report (plain stress-ng --cyclic) is trivially available to any tenant. On a stock non-RT server kernel with deadline scheduling unused, exposure is log noise.

Who can reach it

Local, unauthenticated beyond having the ability to run code on the node - any tenant with shell or pod exec on the host kernel. No special capability is needed in the reported reproducer; it requires a kernel configuration where SCHED_DEADLINE entities and RT priority inheritance are in play (PREEMPT_RT in the report).

What to do

Pick up the stable kernel containing the fix that skips setup_new_dl_entity() for boosted tasks on requeue (commits linked in the record cover several stable branches). Applying it means a kernel update and a reboot of every node, so it belongs in the normal patch train rather than an emergency window - the only configuration worth prioritising is panic_on_warn, where the warning is a tenant-reachable node kill. No upstream mitigation other than not running panic_on_warn is stated in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2024-56583https://git.kernel.org/stable/c/e41074904d9ed3fe582d6e544c77b40c22043c82https://git.kernel.org/stable/c/b600d30402854415aa57548a6b53dc6478f65517

Related entries

All Kernel, userspace & hypervisor entries

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.