CVE-2026-90402

What it actually does

Failure to call device_del() before put_device() in the mhi_register_controller error path for trigger_edl sysfs creation leaves a partially registered device, enabling use-after-free on subsequent operations.

Why it matters to the business

Linux systems using MHI controllers may experience kernel instability, crashes, or local privilege escalation under specific error conditions during device registration.

How an attack unfolds

An attacker with local access triggers the sysfs_create_file failure path in mhi_register_controller, leaving the device registered; subsequent access to the dangling device reference results in use-after-free memory corruption that can be leveraged for arbitrary code execution.

How to fix it

Apply the upstream fix that adds device_del() before put_device() in the error path; rebuild and deploy updated kernels containing the corrected mhi_register_controller logic.

How to confirm the fix worked

Inspect the mhi_register_controller function in the kernel source for the presence of device_del() prior to put_device() in the sysfs error path; verify the change via git log or patch review on affected trees.

Typical attack path

1. Obtain local access on a Linux system with MHI host support
2. Force or wait for mhi_register_controller to reach the trigger_edl sysfs creation step
3. Induce sysfs_create_file failure to enter the incomplete error path
4. Trigger subsequent operations on the still-registered device to hit the use-after-free

How to detect it

Review kernel logs around MHI controller registration for sysfs failures followed by unexpected device references or use-after-free warnings; correlate with local process activity attempting device registration.

What your security team should do

• Prioritize kernel updates for systems exposing MHI controllers
• Monitor upstream stable branches for backports of the cleanup fix
• Limit local unprivileged access on high-value MHI-enabled hosts until patched