CVE-2024-27028

What it actually does

The interrupt handler in the spi-mt65xx driver dereferences the tx_buf pointer from spi_transfer without a NULL check, writing to invalid memory and triggering a kernel crash.

Why it matters to the business

Affected Linux systems using SPI hardware may experience unexpected crashes and downtime, disrupting operations in environments with custom or embedded SPI devices; the issue has persisted across many kernel versions since publication with limited ecosystem exposure outside core kernel trees.

How an attack unfolds

An attacker with local access triggers an SPI transfer that supplies a NULL tx_buf, causing the mt65xx interrupt handler to write to invalid memory and crash the kernel; no named threat actors or ransomware campaigns are associated with this flaw.

How to fix it

Upgrade the Linux kernel to a version containing commit 2342b05ec5342a519e00524a507f7a6ea6791a38 (or equivalent stable backport) to add the required tx_buf NULL check before use in the interrupt handler.

How to confirm the fix worked

Inspect the spi-mt65xx interrupt handler source for an explicit check of trans->tx_buf prior to access; confirm that SPI transfers with NULL tx_buf no longer cause oops or panic on patched kernels.

Typical attack path

1. Obtain local code execution on the target system
2. Initiate an SPI transfer operation with a NULL transmit buffer
3. Allow the mt65xx interrupt handler to execute
4. Trigger NULL pointer write and resulting kernel panic

How to detect it

Review kernel panic and oops logs for entries referencing spi-mt65xx, interrupt handlers, or NULL pointer dereferences during SPI activity; correlate with recent SPI transfer operations.

What your security team should do

• Apply the referenced kernel commit or later stable release across all affected distributions
• Test SPI device drivers and hardware after patching to ensure stability
• Monitor kernel logs for mt65xx-related NULL pointer dereference panics until upgrades complete