CVE-2026-98753: tty: tty_port: restore TTY_IO_ERROR on activation failure
In the Linux kernel, the following vulnerability has been resolved:
tty: ttyport: restore TTYIOERROR on activation failure
Make sure to restore the TTYIOERROR 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 ttyportclose() but not restoring it on activation failure leaves a window where drivers fail to handle the ioctl-hangup race.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.161.1-1
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
A TTY ioctl must race with hangup and open while TTY port activation fails. The affected port is typically gone, powered down, or deregistered, leaving a window for I/O against unavailable hardware or state.
What is the likely impact if the race occurs?
The race can allow I/O attempts on a port that is no longer available. Reported consequences include kernel panics from unclocked accesses or NULL-pointer dereferences.
What can be done if the kernel cannot be updated immediately?
The provided information does not identify a configuration workaround. Reducing exposure would require avoiding the described concurrent TTY ioctl, hangup, and open activity on ports that may be powered down or deregistered.