CVE-2025-68746

What it actually does

Race condition in Tegra210 QSPI driver allows IRQ thread to run after timeout cleanup, leaving curr_xfer pointing to stale memory and failing to clear pending interrupts.

Why it matters to the business

Rare system instability or crashes on affected Linux systems during high CPU load on interrupt-handling cores, potentially disrupting storage or peripheral operations.

How an attack unfolds

An attacker triggers heavy CPU contention on the QSPI interrupt core while initiating SPI transfers; the resulting timeout path cleans up state without nulling curr_xfer, allowing a later-scheduled IRQ thread to dereference invalid memory.

How to fix it

Upgrade the Linux kernel package to version 5.10.178-1 or later on Debian 11 systems; apply vendor backports that clear curr_xfer on timeout and ensure interrupt clearing on failure.

How to confirm the fix worked

Verify the running kernel version contains the commit that adds the curr_xfer NULL check and interrupt clearing on timeout paths; review dmesg for absence of related QSPI timeout warnings after upgrade.

Typical attack path

1. Induce sustained high load on CPU 0
2. Initiate SPI transfers via the tegra210-quad controller
3. Force timeout window before IRQ thread executes
4. Trigger use of stale curr_xfer pointer in IRQ handler

How to detect it

Search kernel logs for repeated QSPI timeout messages followed by unexpected driver state warnings; inspect crash dumps for references to stale curr_xfer pointers in the spi-tegra210-quad driver.

What your security team should do

• Prioritize kernel upgrades on systems using Tegra210 QSPI hardware
• Monitor for upstream stable updates beyond the initial fix
• Test SPI-dependent workloads under CPU contention after patching