VulnerabilityPublished 14 Feb 2026Updated 21 Oct 2026

CVE-2026-23207: Linux kernel · spi: tegra210-quad: Protect curr_xfer check in IRQ handler

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e : update Linux kernel when convenient.

Data as of 26 Oct 2026, 17:30 UTC

Severity

Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS: 0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e, 513587caec66b67243027f26867ad3512f06744f, 84e926c1c272a35ddb9b86842d32fa833a60dfc7 +7

Exploitation evidence

Disclosed: evidence found.
CVE published 14 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected >=5.15.198 <5.16 >=6.1.160 <6.2 >=6.17.13 <6.18	Fixed in edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e 513587caec66b67243027f26867ad3512f06744f 84e926c1c272a35ddb9b86842d32fa833a60dfc7 6.18 6.2 5.16 2ac3a105e51496147c0e44e49466eecfcc532d57
LinuxLinux	Affected >=6.18.2 <6.18.10	Fixed in 6.18.10
LinuxLinux	Affected >=6.12.63 <6.12.80	Fixed in 6.12.80
LinuxLinux	Affected >=6.6.120 <6.6.160	Fixed in 6.6.160

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.

References

Community reviews

Loading reviews…