CVE-2021-47526

What it actually does

Null pointer dereference in the liteuart driver's remove handler when drvdata was never populated during probe, causing platform_get_drvdata to return NULL and trigger a kernel BUG/panic on device removal.

Why it matters to the business

Unexpected kernel crashes and reboots on Linux systems using the liteuart serial driver, leading to service outages, potential data corruption, and unplanned downtime.

How an attack unfolds

A local attacker loads or binds the liteuart driver in a way that skips drvdata initialization in probe, then triggers device removal (via module unload, hotplug, or sysfs) so that the remove path dereferences the unset pointer and panics the kernel.

How to fix it

Upgrade to a Linux kernel containing the fix that guarantees drvdata is stored in probe before remove can run; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Inspect the liteuart probe function in the running kernel source or binary to confirm drvdata assignment occurs; attempt module load/unload cycles on a test system and verify absence of NULL dereference oops.

Typical attack path

1. Gain local user or root access on a Linux host
2. Ensure the liteuart driver is present and can be bound to a device
3. Trigger probe without setting drvdata
4. Invoke device removal to execute the vulnerable remove path
5. Kernel panics resulting in denial of service

How to detect it

Search kernel logs, dmesg, and systemd journal for oops/panic entries containing liteuart, platform_get_drvdata, or serial driver remove paths around the time of unexpected reboots.

What your security team should do

• Prioritize kernel updates on all systems exposing serial or embedded liteuart hardware
• Restrict unprivileged module loading and device hotplug where feasible
• Enable kernel panic logging and watchdog reboots to reduce blast radius of crashes