CVE-2026-98847

What it actually does

Race condition in the SPEAr RTC driver where devm_request_irq enables the alarm interrupt before the MMIO address and spinlock are initialized, allowing the handler to run against uninitialized device state during probe.

Why it matters to the business

May cause kernel instability, crashes, or unpredictable behavior on embedded systems using SPEAr RTC hardware, resulting in device downtime or reduced reliability shortly after kernel updates are released.

How an attack unfolds

An attacker with the ability to influence device probe timing or trigger an alarm IRQ early in initialization can cause the handler to execute before critical structures are ready, leading to undefined kernel behavior.

How to fix it

Update the Linux kernel to a version that reorders initialization so the MMIO address and spinlock are set before devm_request_irq is called for the alarm IRQ.

How to confirm the fix worked

Inspect kernel source or git history for the commit that initializes IRQ state prior to requesting the alarm IRQ; confirm the change is present in running kernels via /proc/version or build logs.

Typical attack path

1. Obtain local access or ability to load the rtc-spear module
2. Trigger conditions that cause the alarm IRQ to fire during probe initialization
3. Exploit the resulting use of uninitialized MMIO or spinlock to induce a crash or memory corruption

How to detect it

Review kernel logs and dmesg output around module load or boot for spear-rtc or alarm IRQ references; watch for unexpected panics or oops during early device initialization.

What your security team should do

• Prioritize kernel updates for systems using SPEAr RTC hardware
• Test updated kernels in lab environments before broad deployment
• Monitor boot logs and crash reports for RTC-related oops on affected devices