CVE-2025-68202— sched_ext: Fix unsafe locking in the scx_dump_state()
Quick assessment
Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞，该漏洞源于锁使用不当，可能导致死锁。
Possible ATT&CK Techniques 1 AI
T1068 · Exploitation for Privilege EscalationAffected Version Matrix 8
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | 07814a9439a3b03d79a1001614b5bc1cab69bcec< 13d1c96d3a9f208bc1aa8642f6362dca25a157d2 |
affected |
07814a9439a3b03d79a1001614b5bc1cab69bcec< b6109750063d3b9aca1c57031213ac5485a06c54 |
affected | ||
07814a9439a3b03d79a1001614b5bc1cab69bcec< 5f02151c411dda46efcc5dc57b0845efcdcfc26d |
affected | ||
6.12 |
affected | ||
< 6.12 |
unaffected | ||
6.12.59≤ 6.12.* |
unaffected | ||
6.17.9≤ 6.17.* |
unaffected | ||
6.18≤ * |
unaffected |
Get alerts for future matching vulnerabilities
Log in to subscribe
I. Basic Information for CVE-2025-68202
Vulnerability Information
Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗
Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.
Vulnerability Title
sched_ext: Fix unsafe locking in the scx_dump_state()
Source: CVE Program / CVE List V5
Vulnerability Description
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().
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞，该漏洞源于锁使用不当，可能导致死锁。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)
Affected Products
II. Public POCs for CVE-2025-68202
| # | POC Description | Source Link | Shenlong Link |
|---|
AI-Generated POC
Premium
No public POC found.
Login to generate AI POCIII. Intelligence Information for CVE-2025-68202
请登录查看更多情报信息。
Other References for CVE-2025-68202 (3)
Same Patch Batch · Linux · 2025-12-16 · 156 CVEs total
| CVE-2025-68284 | 9.8 CRITICAL | libceph: prevent potential out-of-bounds writes in handle_auth_session_key() |
| CVE-2025-40350 | 9.8 CRITICAL | net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ |
| CVE-2025-68263 | 9.8 CRITICAL | ksmbd: ipc: fix use-after-free in ipc_msg_send_request |
| CVE-2025-68301 | 9.8 CRITICAL | net: atlantic: fix fragment overflow handling in RX path |
| CVE-2025-68192 | 9.8 CRITICAL | net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup |
| CVE-2025-68285 | 9.8 CRITICAL | libceph: fix potential use-after-free in have_mon_and_osd_map() |
| CVE-2025-68315 | 9.8 CRITICAL | f2fs: fix to detect potential corrupted nid in free_nid_list |
| CVE-2025-68226 | 8.8 HIGH | smb: client: fix incomplete backport in cfids_invalidation_worker() |
| CVE-2025-68255 | 8.8 HIGH | staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing |
| CVE-2025-68256 | 8.8 HIGH | staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser |
| CVE-2025-68304 | 8.8 HIGH | Bluetooth: hci_core: lookup hci_conn on RX path on protocol side |
| CVE-2025-68314 | 8.8 HIGH | drm/msm: make sure last_fence is always updated |
| CVE-2025-40362 | 8.8 HIGH | ceph: fix multifs mds auth caps issue |
| CVE-2025-68250 | 8.2 HIGH | hung_task: fix warnings caused by unaligned lock pointers |
| CVE-2025-68183 | 7.8 HIGH | ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr |
| CVE-2025-68212 | 7.8 HIGH | fs: Fix uninitialized 'offp' in statmount_string() |
| CVE-2025-68208 | 7.8 HIGH | bpf: account for current allocated stack depth in widen_imprecise_scalars() |
| CVE-2025-68207 | 7.8 HIGH | drm/xe/guc: Synchronize Dead CT worker with unbind |
| CVE-2025-68303 | 7.8 HIGH | platform/x86: intel: punit_ipc: fix memory corruption |
| CVE-2025-68181 | 7.8 HIGH | drm/radeon: Remove calls to drm_put_dev() |
Showing top 20 of 156 CVEs. View all on vendor page → →
IV. Related Vulnerabilities
Same product: Linux
-
CVE-2026-98868
dm-pcache: reject a kset that overruns its segment -
CVE-2026-98867
dm-pcache: bound the logical key offset from persistent memo -
CVE-2026-98866
sched/cache: Introduce task_struct->sched_cache_grp to fix U -
CVE-2026-98865
sched_ext: Don't run ops.dequeue() with a DSQ lock held -
CVE-2026-98864
sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing
Same vendor: Linux
-
CVE-2026-98868
dm-pcache: reject a kset that overruns its segment -
CVE-2026-98867
dm-pcache: bound the logical key offset from persistent memo -
CVE-2026-98866
sched/cache: Introduce task_struct->sched_cache_grp to fix U -
CVE-2026-98865
sched_ext: Don't run ops.dequeue() with a DSQ lock held -
CVE-2026-98864
sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing
V. Comments for CVE-2025-68202
No comments yet