CVE-2026-46257
Kernel Oops in Linux SP804 Timer Driver
Publication date: 2026-06-03
Last updated on: 2026-06-05
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to crash (kernel Oops) on affected ARM32 platforms when the SP804 timer is used in a certain configuration. A kernel Oops can lead to system instability, unexpected reboots, or downtime, potentially disrupting services or applications running on the affected system.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is resolved by updating the Linux kernel to a version where the clocksource/drivers/timer-sp804 code has been fixed to avoid the kernel Oops on ARM32 platforms.
Specifically, the fix involves declaring a dedicated clkevt instance exclusively for the delay timer instead of sharing the same clkevt with sched_clock, ensuring correct operation regardless of SP804 being selected as the sched_clock.
Therefore, the immediate mitigation step is to apply the kernel update or patch that includes this fix.
Can you explain this vulnerability to me?
This vulnerability exists in the Linux kernel's clocksource driver for the SP804 timer on ARM32 platforms. The issue occurs because the delay timer and the sched_clock share the same clkevt instance. On some platforms, if the sched_clock is not properly initialized, the delay timer still tries to use this uninitialized clkevt instance. When the function read_current_timer() calls sp804_read() on this uninitialized sched_clkevt, it causes a kernel Oops (a type of kernel crash).
The fix involves declaring a dedicated clkevt instance exclusively for the delay timer instead of sharing it with the sched_clock. This change ensures that read_current_timer() works correctly regardless of whether SP804 is selected as the sched_clock.