Cloudanix VulnDB

CVE-2026-98753

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in how the operating system manages certain device connections can cause the computer to crash when multiple programs try to open and close those connections at the same time.

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

Failure to restore the TTY_IO_ERROR flag on tty_port activation failure leaves a race window allowing ioctl operations to access powered-down or deregistered ports, resulting in unclocked accesses, NULL-pointer dereferences, or kernel panics during hangup-open sequences.

Why it matters to the business

Systems relying on TTY or serial device handling may experience unexpected kernel crashes or instability under concurrent device open/close/ioctl workloads, though public exploitability remains very low five days after disclosure with no observed exploitation trends.

How an attack unfolds

An attacker with local access triggers concurrent TTY open, ioctl, and hangup operations against a port undergoing activation failure; the missing flag restoration allows the ioctl to proceed on an invalid port state, dereferencing NULL or accessing unclocked memory.

How to fix it

Apply the upstream kernel commit that restores TTY_IO_ERROR on tty_port activation failure; monitor distribution kernel updates for backports of this tty_port fix.

How to confirm the fix worked

Inspect tty_port.c source for the restoration of TTY_IO_ERROR after failed activation; boot patched kernels and confirm no panics occur under synthetic ioctl-hangup-open race workloads on serial devices.

Typical attack path

  1. Obtain local access to trigger TTY device operations
  2. Force or wait for a port activation failure condition
  3. Race ioctl, open, and hangup calls on the affected tty_port
  4. Trigger NULL dereference or unclocked access leading to panic

How to detect it

Search kernel logs and crash dumps for tty_port activation paths combined with unexpected NULL dereferences or TTY_IO_ERROR mishandling during ioctl or hangup sequences; no public exploitation indicators exist given the low EPSS and absence from known exploited lists.

What your security team should do

  • Prioritize kernel updates on systems exposing TTY/serial devices to untrusted local users
  • Review internal workloads using tty_port or serial consoles for exposure to concurrent open/ioctl patterns
  • Monitor kernel oops/panic logs for tty-related dereferences while planning upgrades

The record

In the Linux kernel, the following vulnerability has been resolved: tty: tty_port: restore TTY_IO_ERROR on activation failure Make sure to restore the TTY_IO_ERROR flag if activation fails to prevent I/O attempts on a port that is gone or powered down. This specifically avoids issues like kernel panic due to unclocked accesses or NULL-pointer dereferences when accessing powered down or deregistered ports when a TTY ioctl races with hangup and open. Note that the flag is set again in tty_port_close() but not restoring it on activation failure leaves a window where drivers fail to handle the ioctl-hangup race.

Affected packages

Ecosystem Package Introduced Fixed