CVE-2024-42249

What it actually does

Incorrect early call to spi_maybe_unoptimize_message() inside spi_async() permits a queued SPI message to be modified concurrently while the controller driver still holds references to it, resulting in message corruption.

Why it matters to the business

Embedded and hardware-interfacing Linux systems may encounter unreliable SPI device communication, data corruption on peripherals, or sporadic instability when async SPI transfers are used.

How an attack unfolds

A local attacker triggers rapid or specially timed SPI async submissions that race with the erroneous unoptimize path, allowing the message structure to be altered while the driver is still processing the queued transfer.

How to fix it

Upgrade the Linux kernel to a version containing commit 8b9af6d67517ce4a0015928b3cf35bfd2b1bc1c2; AlmaLinux 8 users should update policycoreutils-gui and policycoreutils-sandbox to 2.9-16.el8 or newer.

How to confirm the fix worked

Confirm the presence of the referenced commit in the kernel changelog or source tree and verify that spi_maybe_unoptimize_message() is invoked only from spi_finalize_current_message().

Typical attack path

1. Obtain local user privileges on an affected Linux system
2. Issue SPI messages via spi_async() under conditions that expose the race window
3. Cause concurrent modification of the in-flight message leading to corruption or crash

How to detect it

Inspect kernel logs for SPI controller errors, message corruption warnings, or related oops/panic entries around async transfer paths.

What your security team should do

• Apply the kernel patch or distribution update as soon as possible
• Review systems using SPI peripherals for unexpected message or transfer errors
• Prioritize updates on embedded and IoT devices where SPI usage is common