EUVD-2026-80620
GHSA-xm4q-v74w-px7x
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Local SPI kernel path (AV:L), reachable only via a rare DMA-map-failure condition not attacker-controlled (AC:H) by a local user able to issue SPI transfers (PR:L); pure NULL-deref crash so C:N/I:N/A:H.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
7DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
spi: Fix DMA mapping ownership on partial map failure
If RX mapping fails after TX mapping succeeds, __spi_map_msg() unmaps TX but leaves tx_sg_mapped set. If TX mapping fails on a later transfer, mappings created for earlier transfers remain active.
In both cases, cur_{tx,rx}_dma_dev have not yet been updated because they are assigned only after every transfer has been mapped. The subsequent spi_unmap_msg() may therefore unmap the TX mapping again or release earlier mappings using a NULL or stale device. Using a NULL device can trigger an oops. An empty SG table does not prevent the NULL dereference because dma_unmap_sg_attrs() accesses the device before checking the entry count.
Publish both mapping devices before mapping starts and unwind all failures through __spi_unmap_msg(). This clears the mapping flags and releases each mapping once with the device that created it.
Publishing the devices before the loop also refreshes them when no transfer needs mapping. No mapping flag is set in that case, so current users do not use the pointers as mapping owners.
AnalysisAI
Kernel oops and duplicate/incorrect DMA unmapping in the Linux kernel SPI core can occur when __spi_map_msg() partially fails: if the RX scatter-gather mapping fails after the TX mapping succeeds, or if a later transfer's TX mapping fails after earlier transfers were mapped, the tx_sg_mapped/cur_tx_dma_dev bookkeeping is left inconsistent, so the subsequent spi_unmap_msg() may unmap a TX mapping twice or call dma_unmap_sg_attrs() with a NULL or stale device struct. Affected systems are Linux kernels 6.11 through the pre-fix stable trees, and exploitation requires local execution on a platform whose SPI controller performs DMA-mapped transfers (typically embedded/ARM SoC hardware) plus an actual DMA mapping failure, which normally arises only under memory pressure or address-space/IOMMU exhaustion and cannot be induced remotely; no public exploit code was identified at time of analysis. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires local execution on a Linux host whose hardware/driver uses DMA-mapped SPI transfers (typical of embedded/ARM SoC platforms), plus an actual DMA mapping failure during __spi_map_msg - i.e., the RX mapping must fail after TX succeeds, or a later transfer's TX mapping must fail. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The vendor CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) is severely inconsistent with the technical description and should be treated as boilerplate auto-scoring, not a real signal. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Vendor-released patch: upgrade to a fixed kernel build - 6.12.110, 6.18.51, 7.2.5, or 7.3-rc1 or later - or cherry-pick the upstream commits cc8354213ad6bd5fb8cc05a3fa3701188d086626, a38051fa2ddedbc8ec15292c55e276880ec5b9a4, 5def8b6aaad44603740786262b95b6f77df52a1c and 367cea239fc93094e5c16a72724800e0358f5c46 from https://git.kernel.org/stable/ (fix details also indexed at https://nvd.nist.gov/vuln/detail/CVE-2026-90012 and EUVD-2026-80620). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all systems running Linux kernel 6.11 or later on embedded/ARM SoC platforms with SPI DMA controllers and restrict local access where possible; within 7 days, obtain the vendor-released kernel patch from your distribution vendor, test it on a representative system, and schedule deployment; within 30 days, deploy the patch across all affected systems, verify the kernel version, and monitor for kernel oops or DMA-related anomalies.
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today