CVE-2025-21657

What it actually does

Incorrect use of rq_lock() instead of raw_spin_rq_lock() in scx_ops_bypass() when iterating CPUs for task re-enqueue can trigger warnings in rq_pin_lock() and __schedule() on offline CPUs or those running higher-class tasks.

Why it matters to the business

Systems may experience scheduler warnings, potential minor performance noise, or instability during task migration on older kernel versions, increasing operational overhead for affected Red Hat Enterprise Linux deployments.

How an attack unfolds

An attacker with local code execution could trigger scheduler paths involving scx_ops_bypass() under specific CPU states to induce warnings or unexpected scheduling behavior, though the primary issue manifests as a locking assertion rather than direct code execution.

How to fix it

Upgrade all affected kernel packages to the fixed versions listed for each product, specifically 0:2.6.32-573.35.1.el6 or later for the Red Hat rhel_eus 6.7 variants.

How to confirm the fix worked

Verify kernel package versions match or exceed the fixed releases; confirm absence of the rq_balance_callback warning in dmesg or logs after applying updates and exercising scheduler paths.

Typical attack path

1. Gain local execution on an affected system
2. Trigger sched_ext task migration or bypass operations across CPUs
3. Induce conditions where rq_lock() is called on offline or high-priority task CPUs
4. Observe or exploit resulting scheduler warnings and state inconsistencies

How to detect it

Search kernel logs and dmesg for the specific balance_callback warning string; review scheduler-related traces around PID 0 and CPU offline events for signs of prior triggering.

What your security team should do

• Prioritize patching kernel packages on all RHEL 6.7 systems within standard maintenance windows
• Monitor for scheduler warnings in production kernels until patches are deployed
• Review downstream package dependencies for any additional updates required