CVE-2026-90336

What it actually does

Use-after-free in the Linux kernel serial core: uart_register_driver leaves drv->state and drv->tty_driver pointing to freed memory on tty_alloc_driver or tty_register_driver failure, allowing subsequent probes to pass dangling pointers to uart_add_one_port when drv->state is misused as a registration flag.

Why it matters to the business

Kernel instability or arbitrary code execution risk on systems that rely on serial ports (embedded, servers, IoT), potentially causing crashes during device probe or registration retry after transient allocation failures.

How an attack unfolds

An attacker with local access triggers repeated uart_register_driver failures (via memory pressure or failslab-style faults) on a serial driver such as PL011, then forces re-binding so the driver skips registration and supplies the freed state object to uart_add_one_port, leading to use-after-free.

How to fix it

Apply the upstream fix that clears drv->state and drv->tty_driver on failure paths inside uart_register_driver, equivalent to the cleanup already performed by uart_unregister_driver; rebuild and deploy the corrected kernel.

How to confirm the fix worked

Confirm the patched kernel source contains the explicit pointer-clearing statements on both failure paths; re-test registration under memory-pressure conditions (failslab or similar) to verify no dangling pointers remain.

Typical attack path

1. Trigger allocation failure inside tty_alloc_driver or tty_register_driver during uart_register_driver
2. Driver treats non-cleared drv->state as already-registered flag and skips re-registration on next probe
3. uart_add_one_port is called with the dangling state pointer
4. Subsequent access to the freed object produces use-after-free

How to detect it

Search kernel logs for uart_register_driver failure messages followed by repeated probe attempts or warnings from uart_add_one_port; inspect crash dumps for use-after-free patterns involving tty or uart state structures.

What your security team should do

• Prioritize kernel update on any system exposing serial devices or using affected UART drivers
• Monitor for kernel oops or warnings related to uart_register_driver and uart_add_one_port
• Harden serial device probing in embedded deployments to reduce re-probe attack surface