CVE-2021-47195

What it actually does

Use-after-free on the per-controller add_lock mutex: spi_unregister_controller releases the device before unlocking the mutex, allowing the freed memory to be dereferenced during unlock.

Why it matters to the business

Kernel instability or crashes on Linux systems that dynamically register or unregister SPI controllers, potentially disrupting hardware-dependent services and requiring reboots.

How an attack unfolds

An attacker with local access triggers repeated SPI controller registration and unregistration (for example via hot-plug or driver unload sequences) to race the mutex unlock against the device release, resulting in a use-after-free that can be leveraged for denial of service or further memory corruption.

How to fix it

Apply the upstream fix that moves put_device after mutex_unlock (commit 6098475d4cb4 and any backports) or upgrade to a kernel version containing the corrected spi controller release sequence.

How to confirm the fix worked

Inspect the spi_unregister_controller path in the running kernel source or verify that mutex_unlock precedes the final put_device call for the controller device.

Typical attack path

1. Obtain local code execution on a Linux system with SPI bus support
2. Cause or wait for spi_register_controller followed by spi_unregister_controller on the same controller
3. Race the put_device call inside unregister against the subsequent mutex_unlock of add_lock
4. Trigger the use-after-free to induce a kernel oops or panic

How to detect it

Review kernel logs for oops or panic messages mentioning spi_controller_release, add_lock, or use-after-free in the SPI subsystem; correlate with processes performing SPI device hot-plug or driver unload operations.

• spi_controller_release
• mutex_unlock.*add_lock
• spi_unregister_controller

What your security team should do

• Prioritize kernel updates containing the mutex ordering fix on all systems exposing SPI devices
• Audit custom or out-of-tree SPI drivers for similar release ordering issues
• Monitor for kernel oops reports referencing spi_controller_release or add_lock