Cloudanix VulnDB

CVE-2026-89740

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A memory-handling mistake in the Linux kernel for certain serial ports can cause crashes when hardware devices are added or removed in specific orders.

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

What it actually does

The vulnerability leaves a dangling pointer in the imx_uart_ports[] array after a port addition fails or after removal, because the entry is not cleared and operations are not serialized, allowing a sibling probe to register a shared console through the stale reference and trigger use-after-free or invalid access.

Why it matters to the business

Embedded Linux systems using i.MX UART hardware may experience kernel instability or crashes during device probe and removal sequences, increasing downtime risk on affected platforms even though public exploitation remains unlikely.

How an attack unfolds

An attacker with local access to the system performs a sequence of UART device unbind and rebind operations that interleave sibling probes with the window where a stale pointer remains in the ports table, causing the console registration path to dereference invalid memory.

How to fix it

Apply the upstream fix that keeps the table entry valid through uart_remove_one_port, clears it afterward, and protects addition/removal together with table updates; upgrade to a patched Linux kernel that includes the serial: imx serialization change.

How to confirm the fix worked

Confirm the kernel source contains the updated probe/remove logic that rejects occupied slots and clears entries; re-test unbind/rebind sequences under KASAN on representative i.MX hardware to verify absence of dangling pointer reports.

Typical attack path

  1. Obtain local access to an affected i.MX system
  2. Unbind a sibling UART device
  3. Unbind the console UART device
  4. Rebind the sibling UART to trigger stale table access during probe

How to detect it

Inspect kernel logs and dmesg for KASAN or oops messages referencing imx_uart_ports or uart_add_one_port during probe and remove operations on i.MX platforms; correlate with device unbind/rebind events in audit or udev logs.

What your security team should do

  • Prioritize kernel updates on i.MX-based devices within standard patch cycles given low EPSS and absence from KEV
  • Limit local unprivileged access to device sysfs bind/unbind interfaces where feasible
  • Monitor vendor kernel advisories for the exact fixed version applicable to each distribution

The record

In the Linux kernel, the following vulnerability has been resolved: serial: imx: serialize imx_uart_ports[] lifetime imx_uart_probe() publishes its devm-allocated port in imx_uart_ports[] before uart_add_one_port() because console setup uses the table. The entry is not cleared when adding the port fails or after removal, leaving a dangling pointer. A sibling probe can register the shared console through that stale entry. This was reproduced under KASAN on QEMU mcimx6ul-evk by unbinding a sibling UART, unbinding the console UART and rebinding the sibling. Keep the entry valid through uart_remove_one_port(), then clear it. Protect port addition and removal together with their table updates so sibling operations cannot interleave. Reject an occupied slot rather than clobbering an active port during a duplicate-line probe.

Affected packages

Ecosystem Package Introduced Fixed