CVE-2026-53384

What it actually does

This flaw is a Linux kernel use-after-free condition in the DesignWare 8250 serial driver. During device probing, the driver registers an 8250 serial port before registering a clock notifier. If clock notifier registration fails, the probe path exits with an error but does not unregister the already-registered serial port. The serial port slot can remain active while its driver-private data has already been freed, leaving stale pointers reachable through serial callbacks such as serial input/output handlers. Subsequent access to the affected serial port can trigger memory corruption, kernel crashes, or potentially kernel-level code execution depending on exploitability in a given platform configuration.

Why it matters to the business

Successful exploitation could allow an attacker or malicious device interaction to destabilize affected Linux systems, causing crashes or potentially gaining kernel-level control. The most likely operational impact is denial of service on systems using the affected DesignWare 8250 serial driver path, especially embedded, appliance, industrial, network, or server platforms that expose or depend on serial hardware. Although the CVSS score is critical, public exploitation is not currently reported, EPSS is low, and it is not listed in CISA KEV, so remediation should be prioritized based on whether affected kernels and this serial driver are present in production or exposed device-management paths.

How an attack unfolds

An attacker must cause or take advantage of a failed probe sequence for a DesignWare 8250 serial device where the port is registered but clock notifier registration fails. Because the error path leaves the 8250 port registered, the kernel retains references to driver data that has been released. The attacker then triggers access to the stale serial port entry, for example through serial device interaction, driver rebinding, hotplug-like behavior, or system activity that invokes the registered serial callbacks. That access can dereference freed memory, producing a kernel crash or, under favorable memory-reuse conditions, controlled memory corruption. Weaponizing this into code execution would require precise kernel memory grooming and platform-specific knowledge, while denial of service is the more straightforward outcome.

How to fix it

Upgrade to a Linux kernel release that includes the fix for the 8250_dw probe error path, specifically unregistering the 8250 port when clk_notifier_register() fails. If a vendor distribution is used, apply the vendor kernel update rather than only relying on upstream version numbers. If immediate patching is not possible, reduce exposure by disabling unused serial hardware, blacklisting or not loading the affected 8250_dw driver where operationally safe, preventing untrusted users from interacting with serial devices, limiting device rebinding and hardware-management access to trusted administrators, and using kernel hardening features such as KASLR, slab freelist hardening, lockdown mode, and restricted access to /dev/mem and debug interfaces. Rebooting clears stale registered port state, but reboot is only a temporary mitigation unless the kernel is patched.

How to confirm the fix worked

Confirm the running kernel contains the patch that unregisters the 8250 port on clk_notifier_register() failure in the serial 8250 DesignWare driver. Validate through vendor advisory status, package changelog, or source inspection of drivers/tty/serial/8250/8250_dw.c for the corrected error path. On running systems, check whether the affected driver is present or loaded using module, kernel configuration, and device inventory checks such as lsmod, modinfo, dmesg, and /sys/bus/platform/drivers inspection. After patching, reboot into the updated kernel and confirm uname/package versions match the fixed vendor release. For exposure validation, review boot and kernel logs for 8250_dw probe failures, clock notifier failures, stale ttyS registrations, KASAN use-after-free reports, kernel oopses, or crashes involving 8250_dw, serial8250, serial_in, or serial_out.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with the DesignWare 8250 serial driver in use or available.
2. Cause or wait for a probe failure after serial8250_register_8250_port() succeeds but clk_notifier_register() fails.
3. Leave the affected 8250 serial port slot registered with stale private driver data.
4. Trigger access to the affected serial port through serial I/O, console interaction, device rebinding, or other kernel paths that call the saved callbacks.
5. Use the resulting use-after-free to crash the kernel or attempt platform-specific memory corruption for privilege escalation or code execution.

How to detect it

Post-exploitation detection is difficult because this is a kernel memory-safety flaw and successful exploitation may leave few application-level traces. Focus on kernel, boot, crash, and audit telemetry. Review dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops, netconsole, and hypervisor or BMC console logs for evidence of 8250_dw probe errors, clock notifier registration failures, serial8250 activity followed by use-after-free warnings, kernel oopses, panics, or unexplained reboots. If KASAN, KFENCE, or kernel crash dumping is enabled, search reports for freed object access involving dw8250, serial8250, serial_in, serial_out, or ttyS device access. Also review audit logs or EDR telemetry for unusual writes to sysfs driver bind/unbind paths, unexpected module loading/unloading, repeated access to serial device nodes, or device-management activity shortly before a kernel crash. Absence of logs does not rule out exploitation, especially if the system panicked before logs were persisted.

• BUG: KASAN: use-after-free
• KASAN: use-after-free
• KFENCE: use-after-free
• 8250_dw
• dw8250_probe
• clk_notifier_register
• serial8250_register_8250_port
• serial8250_unregister_port
• serial_in
• serial_out
• ttyS
• Unable to handle kernel paging request
• kernel BUG at drivers/tty/serial/8250
• drivers/tty/serial/8250/8250_dw.c
• /sys/bus/platform/drivers/8250_dw/bind
• /sys/bus/platform/drivers/8250_dw/unbind
• /dev/ttyS0
• /dev/ttyS1
• /var/crash
• /sys/fs/pstore

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and virtualization hosts for kernels that include or load the DesignWare 8250 serial driver.
• Prioritize patching systems where serial hardware, management consoles, device rebinding, or physical/peripheral access is available to lower-trust users or devices.
• Apply the appropriate vendor kernel update and reboot systems into the fixed kernel.
• Where patching is delayed, disable unused serial devices or prevent loading of the affected driver if it is not required.
• Restrict access to serial device nodes, kernel debug interfaces, module loading, and device bind/unbind controls to trusted administrators only.
• Enable or verify kernel hardening controls such as KASLR, slab freelist hardening, module signature enforcement, and lockdown mode where compatible.
• Monitor kernel logs for 8250_dw probe failures, clock notifier registration failures, KASAN use-after-free reports, and kernel oops or panic events involving serial8250 paths.
• Treat unexpected kernel crashes involving 8250_dw or serial8250 as potentially security-relevant and preserve logs, vmcore dumps, and device state for forensic review.