Live › vulnerability › CVE-2026-98753
Go to dashboardA race between a TTY ioctl and a hangup or open can leave a TTY port in a state where I/O is attempted on a port that is gone or powered down. The sources describe the result as possible kernel panic or NULL-pointer dereference, and the fix restores the TTY_IO_ERROR flag when port activation fails.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the affected tty_port code, most likely hosts with serial or TTY-backed hardware where ports can be hung up or powered down. Systems without such devices are unlikely to hit the race, but the sources do not say which configurations are exposed.
No product ranges from the sources yet.
uname -r and compare it to the fixed kernel release listed in the advisory, which the sources do not nameEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98753")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.