Cloudanix VulnDB

CVE-2025-68202

None

CVSS

—

EPSS

0.2%

Published

Dec 16, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel scheduling bug can cause computers using certain real-time settings to freeze or crash.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Inconsistent locking state between hardirq and non-hardirq contexts in scx_dump_state() on CONFIG_PREEMPT_RT kernels, where rq_lock/unlock is used instead of rq_lock_irqsave/irqrestore, allowing potential deadlock on rq->__lock.

Why it matters to the business

Real-time Linux kernel deployments using sched_ext may experience system hangs or crashes that interrupt workloads; low urgency given absence from KEV, stable low EPSS, and no reported threat actor activity despite 315 days since publication.

How an attack unfolds

An attacker or workload triggers sched_ext error paths that schedule irq_work calling scx_dump_state(); on PREEMPT_RT kernels the sleepable lock collides with interrupt-context acquisition of the same rq lock, producing deadlock. No named APT groups or ransomware campaigns are associated.

How to fix it

Upgrade affected packages to the listed fixed versions: gitaly-fips-17.7, gitaly-backup-fips-17.7, gitaly-git-fips-17.7 and gitaly-init-cgroups-fips-17.7 to 17.7.3-r3; Linux kernel to commit 13d1c96d3a9f208bc1aa8642f6362dca25a157d2 or later stable trees.

How to confirm the fix worked

Verify running kernel contains commit 13d1c96d3a9f208bc1aa8642f6362dca25a157d2; confirm absence of lockdep warnings mentioning scx_dump_state and rq->__lock after exercising sched_ext error paths; test on PREEMPT_RT build.

Typical attack path

  1. Enable sched_ext and CONFIG_PREEMPT_RT
  2. Induce scx_ops error condition
  3. Trigger irq_work execution of scx_dump_state while holding rq lock from interrupt context
  4. Observe lockdep deadlock report or system hang

How to detect it

Search kernel logs and dmesg for lockdep reports containing scx_dump_state, raw_spin_rq_lock_nested, and rq->__lock; inspect irq_work and sched_tick call traces on PREEMPT_RT builds.

  • scx_dump_state+0x3b3
  • raw_spin_rq_lock_nested
  • inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W}
  • scx_ops_error_irq_workfn

What your security team should do

  • Apply the listed fixed package and kernel versions immediately on PREEMPT_RT systems
  • Enable lockdep and monitor kernel logs for rq lock usage bugs
  • Disable sched_ext on real-time kernels until patched if workload stability is critical
  • Track EPSS trend and re-evaluate if exploitation maturity increases

The record

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix unsafe locking in the scx_dump_state() For built with CONFIG_PREEMPT_RT=y kernels, the dump_lock will be converted sleepable spinlock and not disable-irq, so the following scenarios occur: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. irq_work/0/27 [HC0[0]:SC0[0]:HE1:SE1] takes: (&rq->__lock){?...}-{2:2}, at: raw_spin_rq_lock_nested+0x2b/0x40 {IN-HARDIRQ-W} state was registered at: lock_acquire+0x1e1/0x510 _raw_spin_lock_nested+0x42/0x80 raw_spin_rq_lock_nested+0x2b/0x40 sched_tick+0xae/0x7b0 update_process_times+0x14c/0x1b0 tick_periodic+0x62/0x1f0 tick_handle_periodic+0x48/0xf0 timer_interrupt+0x55/0x80 __handle_irq_event_percpu+0x20a/0x5c0 handle_irq_event_percpu+0x18/0xc0 handle_irq_event+0xb5/0x150 handle_level_irq+0x220/0x460 __common_interrupt+0xa2/0x1e0 common_interrupt+0xb0/0xd0 asm_common_interrupt+0x2b/0x40 _raw_spin_unlock_irqrestore+0x45/0x80 __setup_irq+0xc34/0x1a30 request_threaded_irq+0x214/0x2f0 hpet_time_init+0x3e/0x60 x86_late_time_init+0x5b/0xb0 start_kernel+0x308/0x410 x86_64_start_reservations+0x1c/0x30 x86_64_start_kernel+0x96/0xa0 common_startup_64+0x13e/0x148 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rq->__lock); <Interrupt> lock(&rq->__lock); *** DEADLOCK *** stack backtrace: CPU: 0 UID: 0 PID: 27 Comm: irq_work/0 Call Trace: <TASK> dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 print_usage_bug+0x42e/0x690 mark_lock.part.44+0x867/0xa70 ? __pfx_mark_lock.part.44+0x10/0x10 ? string_nocheck+0x19c/0x310 ? number+0x739/0x9f0 ? __pfx_string_nocheck+0x10/0x10 ? __pfx_check_pointer+0x10/0x10 ? kvm_sched_clock_read+0x15/0x30 ? sched_clock_noinstr+0xd/0x20 ? local_clock_noinstr+0x1c/0xe0 __lock_acquire+0xc4b/0x62b0 ? __pfx_format_decode+0x10/0x10 ? __pfx_string+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 lock_acquire+0x1e1/0x510 ? raw_spin_rq_lock_nested+0x2b/0x40 ? __pfx_lock_acquire+0x10/0x10 ? dump_line+0x12e/0x270 ? raw_spin_rq_lock_nested+0x20/0x40 _raw_spin_lock_nested+0x42/0x80 ? raw_spin_rq_lock_nested+0x2b/0x40 raw_spin_rq_lock_nested+0x2b/0x40 scx_dump_state+0x3b3/0x1270 ? finish_task_switch+0x27e/0x840 scx_ops_error_irq_workfn+0x67/0x80 irq_work_single+0x113/0x260 irq_work_run_list.part.3+0x44/0x70 run_irq_workd+0x6b/0x90 ? __pfx_run_irq_workd+0x10/0x10 smpboot_thread_fn+0x529/0x870 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x305/0x3f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x40/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> This commit therefore use rq_lock_irqsave/irqrestore() to replace rq_lock/unlock() in the scx_dump_state().

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 6.12.0 6.12.59
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.9.1.160000.2.6
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.9.1

Related vulnerabilities