EUVD-2026-80541
GHSA-m3pj-6mpg-h767
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local IIO interface access (AV:L, PR:L), a probabilistic RCU-grace race (AC:H), and availability-dominant UAF crash (A:H) with no real confidentiality (C:N) and only incidental integrity (I:L).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
6DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
iio: buffer: Make IIO DMA fence release RCU-safe
The dma_fence documentation states that if a custom release implementation is provided, the dma_fence object must be freed in an RCU-safe way. The current iio_dma_fence implementation uses kfree(), which might result in a use-after-free.
Remove the custom release implementation. This makes the DMA fence core fall back to dma_fence_free(), which calls kfree_rcu() on the fence. This requires that the fence be the first member of struct iio_dma_fence.
Using the default release method for extended DMA fence structures is a common pattern.
AnalysisAI
A race-condition use-after-free in the Linux kernel's IIO (Industrial I/O) buffer DMA-fence implementation allows a local attacker with access to an IIO device exposing the DMABUF buffer interface to corrupt kernel memory by racing the fence's teardown against lockless RCU readers - the custom release path calls kfree() rather than deferring the free through RCU or the standard dma_fence_free() helper. The flaw affects kernels that include the IIO DMABUF buffer support introduced in 6.11 and was fixed in 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1; exploitation requires a vulnerable IIO DMABUF-capable device, a build with that support enabled, and a timing-dependent race window, so it is local-only and not deterministic. …
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 a local process with access to an IIO device that exposes the DMABUF buffer interface (introduced in kernel 6.11, typically high-speed ADC/industrial-I/O hardware); the kernel must be built with IIO buffer DMABUF support. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | This is a race-condition use-after-free in the Linux kernel IIO buffer DMA-fence path, not the confidentiality breach its metadata implies. … 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 | Apply the vendor-released patch by upgrading the kernel to 6.12.110, 6.18.51, 7.2.5, or 7.3-rc1 (or later), or cherry-pick upstream commits 311595dc0b5621f74d8eb4dc38ef4efcdfe7e769, 06a9460b8b792e109cbc934a856d02e5cff217ef, 11cef99491117d4264603df159c4ff5f3845a059 and 8662e56c31cf23b61ca3d11b516efb94c35b8026 per the git.kernel.org stable links and the advisory at https://nvd.nist.gov/vuln/detail/CVE-2026-89941; note that the dirty-page/pointer arithmetic fix requires the dma_fence to be the first member of struct iio_dma_fence, so the commit must be applied as a unit rather than partially backported. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory Linux systems running kernels that include IIO DMABUF buffer support introduced in 6.11 and identify any hosts exposing a vulnerable IIO DMABUF-capable device to local users; restrict device access to trusted users and monitor for kernel crashes. …
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