Cloudanix VulnDB

CVE-2026-98748

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in a Linux serial port driver can let a local attacker corrupt kernel memory, potentially crashing the system or gaining elevated access.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in brcmuart_remove() where brcmuart_handle_irq() can re-arm priv->hrtimer after the port is unregistered but before the timer is cancelled, allowing brcmuart_hrtimer_func() to dereference already-freed priv memory.

Why it matters to the business

Kernel memory corruption on systems using the bcm7271 UART driver can cause crashes, denial of service, or potential local privilege escalation, disrupting embedded or networking devices and requiring urgent patching on affected Linux kernels.

How an attack unfolds

An attacker with local access triggers repeated receive-timeout interrupts while the driver module is being removed; the race between interrupt re-arming the hrtimer and the remove path freeing memory lets the timer callback execute on freed objects.

How to fix it

Apply the upstream fix that unregisters the port via serial8250_unregister_port() before cancelling the hrtimer so interrupts cannot re-arm it; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Inspect kernel source for the corrected ordering of serial8250_unregister_port() before hrtimer_cancel() in brcmuart_remove(); boot test the patched kernel and confirm no use-after-free reports under interrupt load during module removal.

Typical attack path

  1. Obtain local code execution on target Linux system
  2. Load or ensure bcm7271 UART driver is active with hardware flow control
  3. Trigger driver removal or module unload sequence
  4. Rapidly generate receive-timeout interrupts to re-arm hrtimer
  5. Allow timer callback to execute after priv memory is freed

How to detect it

Search kernel logs and crash dumps for references to brcmuart_hrtimer_func, use-after-free in the 8250_bcm7271 path, or slab corruption during UART port removal; correlate with module unload events.

  • brcmuart_hrtimer_func
  • brcmuart_remove
  • use-after-free.*8250_bcm7271

What your security team should do

  • Immediately identify all systems running the 8250_bcm7271 driver and schedule kernel updates
  • Prioritize patching on multi-user or networked devices where local access is plausible
  • Monitor kernel logs for oops or slab corruption involving brcmuart_hrtimer_func until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: serial: 8250_bcm7271: fix use-after-free in brcmuart_remove() brcmuart_handle_irq() starts priv->hrt to work around a receive-timeout quirk of the 8250 core when hardware flow control is enabled; the timer callback brcmuart_hrtimer_func() dereferences priv. brcmuart_remove() cancels the hrtimer before it unregisters the port, so a receive-timeout interrupt that arrives in between re-arms the timer. After devm frees priv, the callback runs on freed memory. Unregister the port before cancelling the hrtimer. serial8250_unregister_port() shuts the port down and frees its IRQ, so brcmuart_handle_irq() can no longer restart the timer, and the final hrtimer_cancel() drains any timer that was armed before or during the unregister. This issue was found by an in-house static analysis tool.

Affected packages

Ecosystem Package Introduced Fixed