CVE-2026-98892
NoneCVSS
—
EPSS
0.2%
Published
Oct 23, 2026
CISA due date
—
Cloudanix analysis
A bug in how the operating system reads certain error reports from hardware controllers could let a malicious controller cause crashes or other problems on the computer.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The arm_scmi BASE_ERROR_EVENT handler used the error_status count to copy a variable-length report array without verifying that the received payload buffer actually contained that many entries, allowing processing of truncated or malformed notifications.
Why it matters to the business
Systems using the arm_scmi firmware interface may experience crashes, unexpected reboots, or undefined behavior when handling error notifications from the SCMI controller, potentially disrupting hardware management and availability on affected Linux deployments.
How an attack unfolds
An attacker with the ability to inject or manipulate SCMI notifications (for example via a compromised firmware or hypervisor) crafts a BASE_ERROR_EVENT message whose reported entry count exceeds the actual payload length; the kernel parser then reads past the end of the buffer while copying reports.
How to fix it
Apply the upstream kernel commit that adds explicit payload-size validation before copying the BASE_ERROR_EVENT report array; rebuild and deploy the fixed kernel image on all affected systems.
How to confirm the fix worked
Confirm the validation check for payload length versus reported entry count is present in the arm_scmi notification parser; test by sending deliberately truncated BASE_ERROR_EVENT messages and verifying they are rejected without kernel faults.
Typical attack path
- Obtain ability to deliver crafted SCMI notifications to the kernel
- Construct BASE_ERROR_EVENT with error_status count larger than supplied payload bytes
- Trigger notification delivery path in the arm_scmi driver
- Kernel performs unchecked copy of report array leading to memory corruption or crash
How to detect it
Search kernel logs and crash dumps for arm_scmi notification handling paths, unexpected oops or panic messages near BASE_ERROR_EVENT processing, or evidence of memory corruption during SCMI error event handling.
What your security team should do
- Prioritize patching Linux kernels that include the arm_scmi driver within the next maintenance window
- Monitor upstream stable and distribution kernel updates for the referenced validation fix
- Review systems exposing SCMI interfaces for additional hardening or isolation controls
The record
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size BASE_ERROR_EVENT carries a variable number of message reports, with the count encoded in error_status. The notification parser used that count without checking whether the received payload contained all reported entries. Reject truncated payloads before copying the report array.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|