CVE-2024-58090 Affecting kernel-64k-debug-modules-internal package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS9-KERNEL64KDEBUGMODULESINTERNAL-9582297
- published1 Apr 2025
- disclosed27 Mar 2025
Introduced: 27 Mar 2025
NewCVE-2024-58090 (opens in a new tab)How to fix?
There is no fixed version for Centos:9 kernel-64k-debug-modules-internal.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-debug-modules-internal package and not the kernel-64k-debug-modules-internal package as distributed by Centos.
See How to fix? for Centos:9 relevant fixed versions and status.
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().
References
- https://access.redhat.com/security/cve/CVE-2024-58090
- https://git.kernel.org/stable/c/0362847c520747b44b574d363705d8af0621727a
- https://git.kernel.org/stable/c/1651f5731b378616565534eb9cda30e258cebebc
- https://git.kernel.org/stable/c/288fdb8dcb71ec77b76ab8b8a06bc10f595ea504
- https://git.kernel.org/stable/c/321794b75ac968f0bb6b9c913581949452a8d992
- https://git.kernel.org/stable/c/68786ab0935ccd5721283b7eb7f4d2f2942c7a52
- https://git.kernel.org/stable/c/82c387ef7568c0d96a918a5a78d9cad6256cfa15
- https://git.kernel.org/stable/c/84586322e010164eedddfcd0a0894206ae7d9317
- https://git.kernel.org/stable/c/b927c8539f692fb1f9c2f42e6c8ea2d94956f921