Cloudanix VulnDB

CVE-2026-98751

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel can let commands meant for serial ports run after the port has already been shut down, which may cause crashes or instability on affected machines.

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

What it actually does

Race condition between break ioctls (TCSBRK/TCSBRKP) and tty hangup allows break signalling to reach a tty driver after the device has been shut down or powered off, violating driver expectations during shutdown.

Why it matters to the business

Linux systems handling serial or console devices may experience instability or unexpected driver callbacks after device removal, increasing operational risk for embedded, server, and desktop deployments until patched.

How an attack unfolds

An attacker with local access triggers concurrent break ioctl calls and hangup events on a tty device; the race allows the break operation to execute after the driver has been torn down, potentially leading to use-after-free or invalid driver invocations.

How to fix it

Update the Linux kernel to a version containing the fix that aborts break signalling on hangup; apply the patch that returns early from break handling after hangup detection and ensure drivers disable break state on shutdown.

How to confirm the fix worked

Verify the kernel source contains the hangup check before break_ctl invocation; confirm the patch commit appears in the running kernel tree and test that concurrent ioctl/hangup sequences no longer reach the driver after shutdown.

Typical attack path

  1. Obtain local user access on a Linux system with tty/serial devices
  2. Open a target tty device and issue TCSBRK or TCSBRKP ioctl
  3. Concurrently trigger hangup (e.g., via close, modem control, or device removal)
  4. Exploit the window where break_ctl is invoked on an already-shutdown driver

How to detect it

Review kernel logs for tty-related warnings or oops around hangup events; inspect audit logs for unusual ioctl sequences on tty devices; no public exploitation artifacts are known.

What your security team should do

  • Prioritize kernel updates on systems exposing tty devices to untrusted users
  • Monitor upstream stable branches for backports of the tty hangup fix
  • Restrict unprivileged access to tty devices via device permissions until patched

The record

In the Linux kernel, the following vulnerability has been resolved: tty: abort break signalling on hangup The break ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down. Drivers must handle this race, but TCSBRK and TCSBRKP should still be aborted to avoid calling back into the driver after a user-controlled timeout (possibly even after the tty has been reopened). Note that drivers should disable any break state on shutdown so just return on hangup (calling break_ctl() again is racy and will most likely fail for drivers handling the race).

Affected packages

Ecosystem Package Introduced Fixed