CVE-2021-47527

What it actually does

Failure to free the UART transmit buffer on final close or driver unbind causes a memory leak for any opened serial port; the uncleared buffer also allows stale data to be transmitted on next open or causes ioctl waits for buffer drain to hang indefinitely.

Why it matters to the business

Systems using serial ports may experience gradual memory exhaustion after repeated open/close cycles or driver reloads, plus intermittent corruption or loss of serial data streams that can disrupt connected devices and management interfaces.

How an attack unfolds

An attacker with local access opens a serial port, triggers repeated close/unbind sequences to exhaust memory, or re-opens the port to inject or observe stale transmit data; the race around buffer clearing can be used to interfere with termios or drain operations.

How to fix it

Update the Linux kernel to a version containing the fix for serial core transmit-buffer handling (post commit 761ed4a94582 plus the follow-on buffer-free changes). Rebuild and reboot with the patched kernel; for console ports ensure the tty-port shutdown path is exercised on unbind.

How to confirm the fix worked

Confirm the kernel source contains the buffer-free logic under the port lock in uart_shutdown / tty_port_close and that the buffer pointer is cleared after release; test by opening/closing serial ports and unloading the driver while monitoring kmemleak or slab usage.

Typical attack path

1. Obtain local shell or userland code execution on the target system
2. Open a serial/tty device node that uses the affected uart_port
3. Perform repeated open/close or module unbind operations to trigger the leak
4. Re-open the port or restart TX to transmit stale buffer contents or hang drain ioctls

How to detect it

Review kernel logs for repeated uart_shutdown or tty_port_close entries around serial device nodes; inspect slabinfo or kmemleak reports for unfreed uart_port transmit buffers after driver unbind; correlate with process activity opening tty devices.

What your security team should do

• Prioritize kernel updates on any system exposing serial ports to untrusted users or scripts
• Monitor EPSS and KEV status; apply patches before the next scheduled maintenance window given the memory-corruption classification
• Add kernel memory-leak detectors (kmemleak, KASAN) to CI test harnesses that exercise serial drivers