CVE-2021-47334

What it actually does

Use-after-free in ibmasm_init_one error paths where mouse_dev and keybd_dev pointers freed via input_free_device in err_free_devices are subsequently passed to ibmasm_free_remote_input_dev in error_send_message, allowing access to already-freed input devices.

Why it matters to the business

Kernel instability, crashes, or potential memory corruption on systems loading the ibmasm module can disrupt server remote management and require unplanned reboots or forensic investigation.

How an attack unfolds

An attacker triggers the ibmasm module initialization under conditions that cause ibmasm_init_remote_input_dev to succeed but later error branches to execute, hitting the double-free/use-after-free sequence in the error handling paths.

How to fix it

Apply the upstream kernel commit introducing the error_init_remote label to ensure proper early return after freeing devices and prevent the subsequent call to ibmasm_free_remote_input_dev on freed objects.

How to confirm the fix worked

Inspect the ibmasm_init_one function in the misc/ibmasm module source for the added error_init_remote label and confirm that ibmasm_free_remote_input_dev is no longer reachable after the free path.

Typical attack path

1. Cause ibmasm_init_one to enter error paths after remote input device allocation
2. Execute err_free_devices branch freeing mouse_dev and keybd_dev
3. Continue execution into error_send_message calling unregister on the freed pointers

How to detect it

Review kernel logs and dmesg output around ibmasm module load times for input device allocation/free warnings or use-after-free reports referencing remote.mouse_dev or remote.keybd_dev.

What your security team should do

• Update to a Linux kernel containing the ibmasm error-handling fix
• Blacklist the ibmasm module via modprobe.d if remote console hardware is not required
• Monitor kernel logs for oops or warnings during ibmasm module load