CVE-2024-38633

What it actually does

Failure to clear the uart_driver_registered flag on MAX3100 driver removal leaves stale state, so a subsequent module load dereferences a NULL pointer inside serial_core_register_port during uart_register_driver, triggering a kernel panic.

Why it matters to the business

Systems using the MAX3100 SPI UART can experience unexpected kernel crashes during driver unload/reload cycles, leading to downtime or loss of serial connectivity on affected hardware.

How an attack unfolds

An attacker with local privileges unloads the max3100 module (or triggers removal of the last device), then reloads it; the unchanged global flag causes the probe routine to hit the NULL dereference in the UART core.

How to fix it

Update the Linux kernel to a version containing commit 21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b or later; rebuild and deploy the fixed kernel image on all affected systems.

How to confirm the fix worked

Confirm the running kernel contains commit 21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b, then perform an insmod-rmmod-insmod cycle on the max3100 module and verify no NULL pointer oops occurs in serial_core_register_port.

Typical attack path

1. Obtain local code execution or shell access
2. Remove the last MAX3100 device or rmmod the driver
3. Reload the module via insmod or automatic reprobe
4. Trigger max3100_probe which calls serial_core_register_port with stale state
5. Cause kernel NULL pointer dereference and panic

How to detect it

Search kernel logs for oops traces referencing max3100_probe followed by serial_core_register_port NULL pointer dereference; correlate with module load/unload events around the crash time.

What your security team should do

• Prioritize kernel upgrade on any system exposing the max3100 driver
• Add the fixed commit to internal kernel build and distribution pipelines
• Monitor for kernel oops reports containing max3100_probe or serial_core_register_port