The vulnerability in the Linux kernel's core scheduling (sched/core) was due to the pick_next_task() function operating on all sibling runqueues (rqs) under a shared core-wide lock. A pick_task() call that releases the rq lock temporarily freed sibling locks, allowing __sched_core_flip(false) to complete mid-selection and rebind rq_lockp() under it. This caused the selection to resume on split locks, touching sibling state without proper protection, and led to releasing a lock that was never taken while leaking another. The fix counts in-flight core-wide selections and makes __sched_core_flip() wait for these to drain, ensuring proper synchronization. Additionally, sched_core_cpu_deactivate() moves the count to the new leader to avoid stale counts biasing future operations.

The vulnerability could lead to inconsistent locking states within the Linux kernel scheduler, potentially causing lock leaks or race conditions during core scheduling flips. This could affect system stability or scheduling correctness. No known exploits in the wild have been reported.

A fix has been implemented in the Linux kernel to address this issue by making core-sched flips wait for in-flight selections to complete. Users should apply the official kernel updates that include this fix once available. Patch status is not yet confirmed from the provided data; check the vendor advisory for current remediation guidance.