CVE-2026-68181

What it actually does

Use-after-free in mei_cl_bus_dev_release() caused by mei_cl_flush_queues() executing without the device lock and by accessing bus->file_list after mei_dev_bus_put(bus) drops the final reference, allowing concurrent modification of freed mei_device structures.

Why it matters to the business

Linux systems using the mei driver may experience kernel memory corruption, crashes, or local privilege escalation, risking service availability and data confidentiality on servers and workstations that depend on Intel MEI hardware.

How an attack unfolds

An attacker triggers rapid mei bus device release while holding references that race with queue flushing and file-list traversal; the missing lock and incorrect ordering of mei_dev_bus_put allow the attacker to reuse the freed mei_device object for arbitrary read/write or control-flow hijacking.

How to fix it

Upgrade the Linux kernel to a version containing the corrected mei_cl_bus_dev_release implementation that acquires the device lock before queue cleanup and performs the WARN traversal before the final put.

How to confirm the fix worked

Confirm the running kernel source contains the updated mei_cl_bus_dev_release function that holds device_lock around flush and list operations and moves the WARN traversal before mei_dev_bus_put.

Typical attack path

1. Obtain local code execution on a system exposing /dev/mei* devices
2. Open and close mei client connections to drive reference counts toward zero
3. Race device release against concurrent mei_cl_flush_queues or WARN_ON traversal
4. Reuse the freed mei_device object to corrupt kernel memory or redirect execution

How to detect it

Inspect kernel logs for oops/panic messages referencing mei_cl_bus_dev_release, mei_cl_flush_queues, or use-after-free in mei_device structures; enable and review KASAN reports on test systems.

What your security team should do

• Prioritize kernel package updates on all systems exposing mei devices
• Enable kernel memory debugging (KASAN or similar) in test environments to validate the fix
• Review mei driver usage in container or VM images and rebuild as needed