fkie_cve-2025-68202
Vulnerability from fkie_nvd
Published
2025-12-16 14:15
Modified
2025-12-18 15:08
Severity ?
Summary
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().
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Fix unsafe locking in the scx_dump_state()\n\nFor built with CONFIG_PREEMPT_RT=y kernels, the dump_lock will be converted\nsleepable spinlock and not disable-irq, so the following scenarios occur:\n\ninconsistent {IN-HARDIRQ-W} -\u003e {HARDIRQ-ON-W} usage.\nirq_work/0/27 [HC0[0]:SC0[0]:HE1:SE1] takes:\n(\u0026rq-\u003e__lock){?...}-{2:2}, at: raw_spin_rq_lock_nested+0x2b/0x40\n{IN-HARDIRQ-W} state was registered at:\n   lock_acquire+0x1e1/0x510\n   _raw_spin_lock_nested+0x42/0x80\n   raw_spin_rq_lock_nested+0x2b/0x40\n   sched_tick+0xae/0x7b0\n   update_process_times+0x14c/0x1b0\n   tick_periodic+0x62/0x1f0\n   tick_handle_periodic+0x48/0xf0\n   timer_interrupt+0x55/0x80\n   __handle_irq_event_percpu+0x20a/0x5c0\n   handle_irq_event_percpu+0x18/0xc0\n   handle_irq_event+0xb5/0x150\n   handle_level_irq+0x220/0x460\n   __common_interrupt+0xa2/0x1e0\n   common_interrupt+0xb0/0xd0\n   asm_common_interrupt+0x2b/0x40\n   _raw_spin_unlock_irqrestore+0x45/0x80\n   __setup_irq+0xc34/0x1a30\n   request_threaded_irq+0x214/0x2f0\n   hpet_time_init+0x3e/0x60\n   x86_late_time_init+0x5b/0xb0\n   start_kernel+0x308/0x410\n   x86_64_start_reservations+0x1c/0x30\n   x86_64_start_kernel+0x96/0xa0\n   common_startup_64+0x13e/0x148\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n\n        CPU0\n        ----\n   lock(\u0026rq-\u003e__lock);\n   \u003cInterrupt\u003e\n     lock(\u0026rq-\u003e__lock);\n\n  *** DEADLOCK ***\n\n stack backtrace:\n CPU: 0 UID: 0 PID: 27 Comm: irq_work/0\n Call Trace:\n  \u003cTASK\u003e\n  dump_stack_lvl+0x8c/0xd0\n  dump_stack+0x14/0x20\n  print_usage_bug+0x42e/0x690\n  mark_lock.part.44+0x867/0xa70\n  ? __pfx_mark_lock.part.44+0x10/0x10\n  ? string_nocheck+0x19c/0x310\n  ? number+0x739/0x9f0\n  ? __pfx_string_nocheck+0x10/0x10\n  ? __pfx_check_pointer+0x10/0x10\n  ? kvm_sched_clock_read+0x15/0x30\n  ? sched_clock_noinstr+0xd/0x20\n  ? local_clock_noinstr+0x1c/0xe0\n  __lock_acquire+0xc4b/0x62b0\n  ? __pfx_format_decode+0x10/0x10\n  ? __pfx_string+0x10/0x10\n  ? __pfx___lock_acquire+0x10/0x10\n  ? __pfx_vsnprintf+0x10/0x10\n  lock_acquire+0x1e1/0x510\n  ? raw_spin_rq_lock_nested+0x2b/0x40\n  ? __pfx_lock_acquire+0x10/0x10\n  ? dump_line+0x12e/0x270\n  ? raw_spin_rq_lock_nested+0x20/0x40\n  _raw_spin_lock_nested+0x42/0x80\n  ? raw_spin_rq_lock_nested+0x2b/0x40\n  raw_spin_rq_lock_nested+0x2b/0x40\n  scx_dump_state+0x3b3/0x1270\n  ? finish_task_switch+0x27e/0x840\n  scx_ops_error_irq_workfn+0x67/0x80\n  irq_work_single+0x113/0x260\n  irq_work_run_list.part.3+0x44/0x70\n  run_irq_workd+0x6b/0x90\n  ? __pfx_run_irq_workd+0x10/0x10\n  smpboot_thread_fn+0x529/0x870\n  ? __pfx_smpboot_thread_fn+0x10/0x10\n  kthread+0x305/0x3f0\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x40/0x70\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1a/0x30\n  \u003c/TASK\u003e\n\nThis commit therefore use rq_lock_irqsave/irqrestore() to replace\nrq_lock/unlock() in the scx_dump_state()."
    }
  ],
  "id": "CVE-2025-68202",
  "lastModified": "2025-12-18T15:08:25.907",
  "metrics": {},
  "published": "2025-12-16T14:15:53.047",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/13d1c96d3a9f208bc1aa8642f6362dca25a157d2"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5f02151c411dda46efcc5dc57b0845efcdcfc26d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b6109750063d3b9aca1c57031213ac5485a06c54"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…