spi: tegra210-quad: Protect curr_xfer check in IRQ handler

Summary

In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Protect curr_xfer check in IRQ handler Now that all other accesses to curr_xfer are done under the lock, protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the spinlock. Without this protection, the following race can occur: CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->curr_xfer) // sees non-NULL spin_lock() tqspi->curr_xfer = NULL spin_unlock() handle_*_xfer() spin_lock() t = tqspi->curr_xfer // NULL! ... t->len ... // NULL dereference! With this patch, all curr_xfer accesses are now properly synchronized. Although all accesses to curr_xfer are done under the lock, in tegra_qspi_isr_thread() it checks for NULL, releases the lock and reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer(). There is a potential for an update in between, which could cause a NULL pointer dereference. To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared curr_xfer, the handler will safely return without dereferencing the NULL pointer.

Timeline

1. Feb 14, 2026, 4:27 PM UTCCVE published
2. Oct 30, 2026, 12:23 PM UTCRecord last updated

Affected versions

• Linux Linux

  From 5.15.198 · fixed in 5.16; From 6.17.13 · fixed in 6.18

• Linux Linux

  From 6.1.160 · fixed in 6.1.191; From 6.6.120 · fixed in 6.6.160; From 6.12.63 · fixed in 6.12.80; From 6.18.2 · fixed in 6.18.10

• KernelLinux

  From 6.6.120 · fixed in 6.6.160; From 6.12.63 · fixed in 6.12.80; From 6.18.2 · fixed in 6.18.10

References 5