---
id: "CVE-2026-98847"
kind: "vulnerability"
aliases: ["CVE-2026-98847"]
title: "Linux kernel: SPEAr RTC probe can race its alarm interrupt handler"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["arm-spear", "embedded", "infrastructure", "linux-kernel"]
not_affected_if: ["no-spear-rtc-hardware"]
published_at: "2026-10-18T16:17:39+00:00"
first_seen_at: "2026-10-23T21:57:17+00:00"
updated_at: "2026-10-25T05:13:05+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98847", "first_seen_at": "2026-10-23T21:57:17+00:00"}]
---

# Linux kernel: SPEAr RTC probe can race its alarm interrupt handler

In the Linux kernel's SPEAr real-time clock driver, the alarm interrupt was requested before the device's register address and spinlock were set up, so the handler could run during probe while that state was still uninitialized. The sources do not describe an attacker-controlled trigger or a concrete impact beyond this ordering bug.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Update the Linux kernel to a release that includes the upstream fix for rtc: spear, initializing the MMIO address and spinlock before devm_request_irq(); the sources do not name fixed versions.

## Timeline

- 2026-10-23T21:57:17+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98847

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

rtc: spear: initialize IRQ state before requesting alarm IRQ

devm_request_irq() enables the interrupt before it returns, so the handler
may run while probe is still initializing the device. Initialize the MMIO
address and spinlock before requesting the alarm IRQ.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_