CVE-2026-89594

What it actually does

The OMAP SSI driver creates a synthetic HSI controller device via hsi_alloc_controller() that does not follow the normal OF/platform device path, so the embedded struct device has no DMA mask. After Linux DMA API hardening, dma_map_sg() and related helpers require a valid dma_mask; without it, SSI/HSI DMA mapping can fail and produce kernel warnings, oopses, or a crash. Primary technical impact is availability loss in the SSI/HSI path (DoS family). The High CVSS CIA ratings reflect that unconstrained or failed kernel DMA setup can, in principle, also yield memory-safety failures, but the published fix is a missing 32-bit dma_mask initialization matching hardware capability.

Why it matters to the business

Linux devices that actually load the TI OMAP SSI/HSI controller—typically embedded, industrial, automotive, or mobile SoC images—can suffer unexpected kernel crashes or serial/HSI path failures and require reboot. The issue is local-only, exploit maturity is none, EPSS is ~0.0017 with a flat 30-day trend, it is not in CISA KEV, and it is not associated with ransomware, so fleet-wide urgency is low except on OMAP-based systems that use this driver. Unpatched exposure is mainly unplanned downtime and support cost on those niches, not a broad enterprise desktop/server risk.

How an attack unfolds

An attacker who already has local, low-privileged access on a Linux system with the omap_ssi driver bound can cause the synthetic SSI controller to attempt scatter-gather DMA mapping. The hardened DMA API then hits the missing dma_mask and typically warns, oopses, or panics, denying service until reboot. No public exploit, named threat actor, or in-the-wild campaign is associated with this CVE. Remote, unauthenticated exploitation is not indicated.

How to fix it

Upgrade the Linux kernel to a build that contains the upstream change 'hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device', which explicitly sets a 32-bit DMA mask on the synthetic SSI controller device. Use the latest stable kernel from the distro or SoC vendor and confirm the patch in the vendor changelog—no per-package fixed versions were supplied with this record. If a kernel update cannot ship immediately, unload or blacklist omap_ssi and unused HSI modules on systems that do not need SSI hardware, and tighten local login and device-node access.

How to confirm the fix worked

Confirm the running kernel changelog or omap_ssi_core source initializes a 32-bit dma_mask on the HSI controller device. On candidate hardware, check that the SSI/HSI device exposes a dma_mask, then exercise HSI/SSI DMA after patching and verify dmesg/journal show no new DMA-API warnings or oopses in omap_ssi. Hosts without OMAP SSI silicon, or that never load the driver, are not exposed.

Typical attack path

1. Obtain local unprivileged access on a Linux host whose kernel includes the OMAP SSI/HSI driver
2. Confirm the SSI controller is present and omap_ssi (or related HSI client) is loaded
3. Cause the SSI/HSI data path to perform DMA mapping on the synthetic controller device
4. Kernel DMA helpers reject or mishandle the mapping because dma_mask is unset
5. Warning, oops, or panic takes the host or HSI communications offline

How to detect it

This defect usually appears as a reliability crash, not stealthy compromise. Search kernel logs (dmesg, journalctl -k, kern.log, pstore, vmcore/kdump) around HSI/SSI activity for DMA-API warnings about a missing or uninitialized dma_mask and for oops/panic stacks in omap_ssi, omap_ssi_core, hsi_alloc_controller, or dma_map_sg. Correlate unexpected reboots of OMAP-based devices with SSI traffic. There are no known attacker tools or campaign artifacts; lack of these messages does not prove the driver was never loaded, only that a crash may not have been recorded.

• omap_ssi
• omap_ssi_core
• omap_ssi.ko
• hsi_alloc_controller
• dma_map_sg
• DMA-API
• uninitialized dma_mask
• dma_mask

What your security team should do

• Inventory Linux images—especially TI OMAP/embedded builds—for omap_ssi, hsi_char, and SSI/HSI devices and patch those first
• Treat non-OMAP fleets as low urgency given local vector, EPSS ~0.0017, no KEV, and no known exploits
• Until patched, restrict local unprivileged access and unused HSI device nodes; blacklist omap_ssi where the hardware is absent
• Watch kernel logs and kdump/pstore for DMA-API and omap_ssi oopses as a stopgap
• Track distro/SoC kernel advisories for the exact backport rather than assuming a generic version number