ghsa-9mh6-8446-rm89
Vulnerability from github
Published
2025-12-16 15:30
Modified
2025-12-16 15:30
Details

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); lock(&rq->__lock);

*** DEADLOCK ***

stack backtrace: CPU: 0 UID: 0 PID: 27 Comm: irq_work/0 Call Trace: 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 ? __pfxlockacquire+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

This commit therefore use rq_lock_irqsave/irqrestore() to replace rq_lock/unlock() in the scx_dump_state().

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-68202"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-16T14:15:53Z",
    "severity": null
  },
  "details": "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": "GHSA-9mh6-8446-rm89",
  "modified": "2025-12-16T15:30:45Z",
  "published": "2025-12-16T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68202"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/13d1c96d3a9f208bc1aa8642f6362dca25a157d2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5f02151c411dda46efcc5dc57b0845efcdcfc26d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b6109750063d3b9aca1c57031213ac5485a06c54"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.