CVE-2024-42245

What it actually does

The flaw causes an O(n) iteration in detach_tasks() during load balancing while holding the runqueue lock, often in softirq context, leading to hard lockups when many pinned tasks exist on a CPU.

Why it matters to the business

Workloads with high thread pinning on Linux systems can trigger system freezes or crashes, disrupting availability and requiring manual intervention or reboots; low urgency given stable low EPSS and absence from KEV.

How an attack unfolds

An attacker with local access creates O(10k) threads affined to a single CPU, forcing the load balancer (with rq lock held) into full iteration over pinned tasks and inducing a hard lockup; unrelated threat actor mentions in input do not indicate active exploitation of this specific issue.

How to fix it

Apply the revert commit d467194018dd536fe6c65a2fd3aedfcdb1424903 in the Linux kernel; for AlmaLinux 8 packages update freeipmi and related components to 1.6.8-1.el8.

How to confirm the fix worked

Verify kernel source contains the revert commit or package version matches the fixed releases; test load balancing under high pinning workloads for absence of lockups.

Typical attack path

1. Obtain local user access on affected Linux kernel
2. Affin many threads to a single CPU
3. Trigger load balancing via scheduling activity
4. Cause rq lock contention leading to hard lockup

How to detect it

Inspect kernel logs for hard lockup reports involving sched/fair or detach_tasks; correlate with processes using high CPU affinity.

• hard lockup
• detach_tasks
• rq lock

What your security team should do

• Prioritize kernel package updates to the listed fixed versions
• Review and limit excessive CPU affinity in critical workloads
• Monitor kernel logs for lockup indicators post-deployment