Cloudanix VulnDB

CVE-2026-93091

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in how the Linux kernel shuts down certain hardware notification features on ARM chips can let the system use already-freed memory, which may crash the machine.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel ARM SCMI notification handling: scmi_notification_exit clears state while transport RX callbacks can still invoke scmi_notify on freed memory; late-init work item on system workqueue can also run after notify_wq and devres release.

Why it matters to the business

Kernel panic or potential local privilege escalation on ARM systems using SCMI firmware interface, risking system crashes and denial of service in embedded and server deployments.

How an attack unfolds

An attacker with local access triggers device remove or probe error path during notification teardown window, allowing an RX interrupt or queued init_work to dereference already-freed notification instance structures.

How to fix it

Apply the upstream fix that quiesces notifications before channel teardown and uses disable_work_sync on late-init work; rebuild and deploy updated kernel images to all affected systems.

How to confirm the fix worked

Confirm kernel source contains the quiesce-before-teardown ordering and disable_work_sync calls in arm_scmi notification exit and probe error paths; test device remove under load to verify no crashes.

Typical attack path

  1. Obtain local code execution or trigger SCMI device unbind/remove
  2. Race notification exit path with incoming transport callback or pending late-init work
  3. Cause scmi_notify or init_work to access freed notification instance
  4. Trigger use-after-free resulting in crash or controlled memory write

How to detect it

Review kernel logs for scmi_notify or notification-related oops/panic traces around device remove events; no widespread exploitation indicators expected given low EPSS and lack of KEV listing.

What your security team should do

  • Prioritize kernel updates on all ARM SCMI-enabled systems within normal patch windows
  • Monitor for related upstream backports in distribution kernels
  • Add SCMI device remove/load stress tests to CI pipelines

The record

In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Quiesce notifications before teardown scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization. The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance. Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts.

Affected packages

Ecosystem Package Introduced Fixed