CVE-2024-42245 is a vulnerability identified in the Linux kernel's CPU scheduler, specifically related to the load balancing logic within the fair scheduler (sched/fair). The issue arose from a patch (commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06) intended to improve task detachment from CPUs by ignoring the env.max_loop limit if all tasks examined were pinned. Pinned tasks are those affined to a specific CPU and cannot be moved. The patch aimed to increase the likelihood of detaching a movable task buried among many pinned tasks. However, this change inadvertently introduced an O(n) complexity iteration in the detach_tasks() function, where n is the number of tasks on a CPU. Since this code executes while holding the runqueue (rq) lock and often in softirq context, it can cause significant CPU lockups if triggered. The vulnerability manifests when a large number of threads (on the order of 10,000) are affined to a single CPU, causing the scheduler to perform extensive iterations under lock, leading to hard system lockups or hangs. After discussions among kernel maintainers, the patch was reverted because the original problem it sought to fix was rare or non-existent, and the introduced side effect was more severe. This vulnerability does not have known exploits in the wild and affects Linux kernel versions containing the problematic commit. No CVSS score has been assigned yet.

For European organizations relying on Linux-based systems, especially those running high-performance computing, virtualization hosts, or container orchestration platforms, this vulnerability could lead to system instability or denial of service through CPU lockups. Systems with workloads that heavily pin large numbers of threads to single CPUs are particularly at risk. This could affect critical infrastructure, cloud service providers, and enterprises using Linux servers for essential services. The impact is primarily on availability, as the vulnerability can cause hard lockups, making affected systems unresponsive and requiring manual intervention or reboot. Confidentiality and integrity are not directly impacted. Given the nature of the vulnerability, exploitation requires specific workload conditions (many pinned threads), which may limit widespread exploitation but could be triggered inadvertently or maliciously in multi-tenant environments or by insider threats.

Organizations should ensure their Linux kernels are updated to versions where this problematic patch has been reverted or fixed by subsequent updates. Specifically, applying the latest stable kernel releases from trusted vendors or distributions is critical. Monitoring and limiting the number of threads pinned to a single CPU can reduce the risk of triggering this vulnerability. System administrators should audit workloads and affinity settings to avoid excessive thread pinning. In environments where custom kernel builds are used, verify that the reverted patch is not present. Additionally, implement resource management policies in container orchestration or virtualization platforms to prevent tenants or users from creating workloads that could cause such CPU affinity extremes. Employing kernel live patching solutions where available can help mitigate the issue without requiring full system reboots.