CVE-2026-80923

What it actually does

Use-after-free caused by a dangling pointer to a tty driver structure that was freed on tty_register_driver failure but never nulled, leading to tty_unregister_driver operating on freed memory during module exit.

Why it matters to the business

Kernel instability or potential code execution on Linux systems that load and unload the xhci USB debug module after a registration failure, disrupting USB and system operations.

How an attack unfolds

An attacker with local access triggers a tty_register_driver failure during xhci debug initialization, leaves the dangling driver pointer, then forces module unload to trigger the use-after-free for privilege escalation or denial of service.

How to fix it

Apply the upstream kernel patch that sets dbc_tty_driver to NULL after a failed tty_register_driver call; rebuild and deploy updated kernel images across affected systems.

How to confirm the fix worked

Review source for dbc_tty_init and dbc_tty_exit to confirm the pointer is cleared on failure; boot with the fixed kernel and force registration failure paths while monitoring for use-after-free reports in dmesg.

Typical attack path

1. Cause tty_register_driver failure in dbc_tty_init
2. Allow xhci_hcd_init to continue despite error
3. Trigger xhci module unload via rmmod or system shutdown
4. dbc_tty_exit checks non-NULL dangling pointer and calls tty_unregister_driver on freed memory

How to detect it

Inspect kernel logs for xhci and tty driver registration failures followed by module unload events; search dmesg or journalctl for use-after-free warnings or oops involving tty_unregister_driver.

What your security team should do

• Prioritize kernel updates containing the fix for production systems using xhci debug capability
• Monitor for module load/unload events involving xhci_hcd in logs
• Disable xhci debug features if not required to reduce attack surface