CVE-2026-98883 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_port: recognize UPIO_AU
My MIPS Alchemy systems generate the following warning during probe of the 8250 driver:
WARNING: drivers/tty/serial/8250/8250_port.c:462 at set_io_from_upio+0xfc/0x124, CPU#0: swapper/0/1 Unsupported UART type 4 [...]
[<80521d40>] set_io_from_upio+0xfc/0x124
[<80521dfc>] serial8250_set_defaults+0x94/0xe0
[<80520fb4>] serial8250_register_8250_port+0x288/0x51c
[<805214ec>] serial8250_probe+0x160/0x1e8
[<8053b5f0>] platform_probe+0x64/0x90
The least invasive fix is to recognize UPIO_AU (type 4) in set_io_from_upio() and do nothing, since all parameters have already been set up in 8250_rt288x.c::au_platform_setup().
Run-tested on Alchemy Au1300 platform.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel serial subsystem relies on a generic driver model to support a wide variety of UART hardware, but specific embedded architectures often require custom initialization sequences that differ from the standard assumptions made by the core 8250 driver. In this instance, MIPS Alchemy systems utilizing the Au1300 platform encountered a warning during the probe phase of the serial port driver because the kernel did not recognize the UPIO_AU hardware type identifier. This oversight resulted in an unsupported UART type error being logged to the console, indicating that the generic initialization routine failed to map the specific I/O access method required by this particular silicon variant. The technical flaw resides within the set_io_from_upio function in drivers/tty/serial/8250/8250_port.c, which serves as a dispatcher for configuring hardware-specific parameters based on the platform-defined UART type. When the driver encounters an unrecognized type value such as four, it triggers a warning stack trace rather than proceeding with initialization or gracefully handling the exception, thereby exposing incomplete error handling logic in the kernel's serial subsystem.
From a security and stability perspective, this vulnerability represents a denial of service condition for local console access on affected MIPS Alchemy systems. While not exploitable by remote attackers to gain code execution, the presence of these warnings can clutter system logs with noise that obscures other critical errors during boot or runtime operations. Furthermore, if the warning indicates a failure in subsequent initialization steps due to the unrecognized type, it could lead to non-functional serial ports, preventing administrators from accessing the console for troubleshooting or management purposes. This aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions, as the code fails to properly validate and handle specific hardware identifiers that are valid within their intended architectural context but appear anomalous to a generic implementation. The issue is further contextualized by ATT&CK technique T1082: System Information Discovery, where an attacker might exploit verbose logging or error messages to gain insight into the kernel version and loaded modules, although in this specific case, the primary impact remains operational rather than informational leakage.
The resolution involves modifying the set_io_from_upio function to explicitly recognize UPIO_AU as a valid UART type identifier. By adding this recognition, the driver acknowledges that the hardware-specific parameters have already been correctly configured by the platform-specific setup routine in 8250_rt288x.c::au_platform_setup. This approach avoids redundant or conflicting initialization attempts and prevents the generation of spurious warning messages. The fix is designed to be minimally invasive, ensuring that existing functionality remains intact while correcting the logic flow for this specific hardware family. Run-testing on the Alchemy Au1300 platform confirms that the warning no longer appears during probe operations, restoring clean boot logs and proper serial port initialization behavior. This patch exemplifies the importance of maintaining parity between generic kernel drivers and architecture-specific requirements in embedded Linux environments to ensure system stability and accurate diagnostic output.