CVE-2024-58090: sched/core: Prevent rescheduling when interrupts are disabled
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Prevent rescheduling when interrupts are disabled
David reported a warning observed while loop testing kexec jump:
Interrupts enabled after irqrouter_resume+0x0/0x50
WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220
kernel_kexec+0xf6/0x180
__do_sys_reboot+0x206/0x250
do_syscall_64+0x95/0x180
The corresponding interrupt flag trace:
hardirqs last enabled at (15573): [<ffffffffa8281b8e>] __up_console_sem+0x7e/0x90
hardirqs last disabled at (15580): [<ffffffffa8281b73>] __up_console_sem+0x63/0x90
That means __up_console_sem() was invoked with interrupts enabled. Further
instrumentation revealed that in the interrupt disabled section of kexec
jump one of the syscore_suspend() callbacks woke up a task, which set the
NEED_RESCHED flag. A later callback in the resume path invoked
cond_resched() which in turn led to the invocation of the scheduler:
__cond_resched+0x21/0x60
down_timeout+0x18/0x60
acpi_os_wait_semaphore+0x4c/0x80
acpi_ut_acquire_mutex+0x3d/0x100
acpi_ns_get_node+0x27/0x60
acpi_ns_evaluate+0x1cb/0x2d0
acpi_rs_set_srs_method_data+0x156/0x190
acpi_pci_link_set+0x11c/0x290
irqrouter_resume+0x54/0x60
syscore_resume+0x6a/0x200
kernel_kexec+0x145/0x1c0
__do_sys_reboot+0xeb/0x240
do_syscall_64+0x95/0x180
This is a long standing problem, which probably got more visible with
the recent printk changes. Something does a task wakeup and the
scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and
invokes schedule() from a completely bogus context. The scheduler
enables interrupts after context switching, which causes the above
warning at the end.
Quite some of the code paths in syscore_suspend()/resume() can result in
triggering a wakeup with the exactly same consequences. They might not
have done so yet, but as they share a lot of code with normal operations
it's just a question of time.
The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling
models. Full preemption is not affected as cond_resched() is disabled and
the preemption check preemptible() takes the interrupt disabled flag into
account.
Cure the problem by adding a corresponding check into cond_resched().
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can let the scheduler run while interrupts are disabled during sensitive resume or kexec-related paths. That is invalid kernel context and can produce warnings or instability. The sources do not show remote exploitation, privilege escalation, or confirmed active abuse.
Executive priority
Treat as a normal-priority kernel maintenance item unless affected systems are highly sensitive to reboot, suspend, or kexec reliability. There is no source-backed evidence of active exploitation, but kernel correctness bugs still warrant timely patching.
Technical view
The flaw is in cond_resched() behavior for PREEMPT_NONE and PREEMPT_VOLUNTARY kernels. A wakeup during syscore suspend or resume can set NEED_RESCHED, causing cond_resched() to invoke schedule() while interrupts are disabled. Full preemption is described as unaffected.
Likely exposure
Exposure is limited to Linux systems running affected kernel builds with PREEMPT_NONE or PREEMPT_VOLUNTARY. Systems using vendor kernels should confirm whether their package includes the stable kernel fixes or Debian LTS updates referenced in the CVE data.
Exploitation context
The provided sources describe a kernel warning found during kexec jump loop testing. KEV is false, and no cited source reports active exploitation. The evidence supports a reliability and kernel correctness concern, not a proven public attack path.
Researcher notes
The key condition is NEED_RESCHED being set during interrupt-disabled syscore suspend or resume, followed by cond_resched(). The fix adds an interrupt-state-aware check. The source data lacks CVSS, CWE, and detailed exploitability analysis.
Mitigation direction
Apply vendor kernel updates that include the referenced stable fixes.
Check Debian LTS advisories if running Debian LTS kernels.
Prioritize systems using PREEMPT_NONE or PREEMPT_VOLUNTARY kernel configurations.
Track vendor guidance for exact fixed package versions.
Reboot into the updated kernel after maintenance approval.
Validation and detection
Inventory Linux kernel versions across servers and appliances.
Check kernel preemption configuration for PREEMPT_NONE or PREEMPT_VOLUNTARY.
Compare installed kernel changelogs against referenced stable commits.
Confirm vendor advisories mark the installed package as fixed.
Review kernel logs for related syscore resume or interrupt warnings.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-58090 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
1ADP providers
11Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Mar 27, 2025, 14:57 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.