CVE-2023-54220

What it actually does

Use-after-free in the 8250 serial driver where port->pm is not cleared on hardware-specific driver unbind, causing serial8250_pm() to invoke a dangling function pointer during subsequent uart_hangup() and uart_change_pm() calls.

Why it matters to the business

Kernel crashes can occur on systems unloading 8250 hardware drivers, leading to denial of service, potential data loss in flight, and unplanned downtime for serial-dependent devices or embedded systems.

How an attack unfolds

An attacker with local access unloads a hardware-specific 8250 driver; approximately ten seconds later a hangup event triggers uart_change_pm() which calls the stale port->pm pointer, resulting in a kernel paging fault and crash. No widespread threat actor campaigns are associated.

How to fix it

Upgrade the Linux kernel to a fixed version such as 4.14.324 or apply the commit 66f3e55960698c874b0598277913b478ecd29573 that clears port->pm on unbind; for ruby3.1 update to 3.1.6-e0 or later equivalent.

How to confirm the fix worked

Verify the running kernel contains the fix commit or version 4.14.324+, attempt driver unload followed by port activity, and confirm absence of the paging request oops; inspect dmesg for clean serial8250_pm() behavior.

Typical attack path

1. Obtain local access or ability to unload kernel modules
2. Unload the hardware-specific 8250 driver module
3. Trigger uart_hangup() on the affected port (e.g., via terminal close or device removal)
4. Observe kernel oops from dereference of freed port->pm function

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for the exact paging request error occurring roughly ten seconds after 8250 driver unload events; correlate with module unload timestamps and uart_hangup traces.

• Unable to handle kernel paging request at virtual address
• serial8250_pm
• uart_change_pm

What your security team should do

• Prioritize kernel upgrades on systems using 8250 serial hardware drivers
• Audit module unload procedures and serial device usage in production workloads
• Monitor for kernel oops events related to uart_change_pm during the next 30 days
• Test the fix in staging environments before broad deployment