EUVD-2026-93182
GHSA-hrh5-h3h2-8q3j
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLocal access to DMA-capable path
-
DeliveryIssue partial dma_sync_single_range_for_*
-
ExploitProduce non-zero tlb_offset crossing page
-
Executionswiotlb copies wrong highmem page
-
ImpactData corruption or stale/leaked page
Vulnerability Assessment
| Exploitation Conditions | Requires a configuration that uses swiotlb bounce buffering together with highmem (historically 32-bit systems or large-memory builds where PhysHighMem() is meaningful), AND a DMA pattern that generates a non-zero tlb_offset - specifically partial syncs through dma_sync_single_range_for_cpu()/for_device() - large enough to cross a page boundary. The flaw is dormant for aligned, full-buffer DMA where tlb_offset is zero. Limiting factors: no remote vector (AV:L), it needs local ability to drive DMA operations, and the impact is wrong-page copy / stale data rather than a directly attacker-controlled primitive, making reliable targeted exploitation difficult. |
| Impact | The input provides a CVSS 3.1 vector of CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (base 7.8), indicating a local, low-complexity, low-privilege flaw with high confidentiality, integrity, and availability impact - the canonical profile for a Linux kernel memory-handling bug. However, the EPSS score is very low at 0.18% (6th percentile), there is no CISA KEV listing, and no public exploit is identified, so despite the HIGH severity rating this is not a demonstrated exploitation priority. The signals are internally consistent rather than conflicting: a local-only vector plus negligible EPSS plus no KEV all point to a real correctness/data-integrity defect that is unlikely to be weaponized at scale. The bug is a swiotlb bounce-buffer page-lookup error that corrupts DMA transfers (wrong-page writes/reads and stale data) rather than an attacker-driven control-flow primitive, so treat it as a stability and data-integrity fix to roll out through normal kernel patching cadence rather than an emergency. Note one nuance to verify: the CVSS AC:L in the input understates the real trigger difficulty - exploitation depends on highmem configurations and non-zero tlb_offset arising from partial DMA syncs, which argues for higher attack complexity (see assessed vector). |
| Exploit ScenarioDerived | On a system using swiotlb bounce buffering with highmem, a local workload (or driver path) performs partial DMA syncs via dma_sync_single_range_for_*() that produce a non-zero tlb_offset crossing a page boundary; swiotlb_bounce() then copies to or from the wrong physical page, corrupting data or leaving stale data in the intended page. No public exploit code is identified at time of analysis, and the realistic outcome is data corruption/disclosure between pages rather than reliable code execution. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Incorrect page-frame/offset bookkeeping in the Linux kernel's swiotlb bounce-buffer code (swiotlb_bounce) can place DMA copies one page away from the intended location whenever a non-zero tlb_offset, produced by partial syncs through dma_sync_single_range_for_cpu()/for_device(), crosses a page boundary. Affected are kernels with swiotlb bounce buffering plus meaningful highmem (typically 32-bit or large-memory builds); because the offset and the page frame are taken from mismatched values, DMA_FROM_DEVICE can overwrite the wrong page while leaving the intended page stale, and DMA_TO_DEVICE can feed data from a page the mapping may not cover, and a lowmem-recorded slot can even be adjusted into highmem and then passed to phys_to_virt(). The assessed vector is local, PR:L (authenticated local access), with AC:H reflecting that the flaw is dormant for aligned full-buffer DMA and needs a DMA pattern that produces a page-crossing offset, so although confidentiality, integrity and availability impact are all rated High, reliable targeted exploitation is difficult; no public exploit code has been identified at time of analysis and EPSS is low at 0.18% (6th percentile), with no CISA KEV listing.
RemediationAI
Vendor-released patches are available: upgrade to Linux 6.12.112, 6.18.54, 7.2.8 or 7.3-rc4 (or the corresponding backports carrying commits 6e53b4d6afbde626255805d438cabb1cac482445, aa4709813b29db89f2307f968db5d24925dcdeb1, 0219b72f5c209732b2f03a8cc0d7240b5e428a99 or b7d7914a9ae3097e63d113007e4fb44d33d515b1), and track the stable/c commits linked from https://nvd.nist.gov/vuln/detail/CVE-2026-98254. Where immediate patching is not possible, the most effective compensating control is to eliminate the trigger condition rather than the code path: audit and rewrite DMA drivers on affected hosts to avoid partial syncs via dma_sync_single_range_for_cpu()/dma_sync_single_range_for_device() with ranges that can cross a page boundary, using full-buffer dma_sync_single_for_cpu()/device() syncs instead so tlb_offset stays zero - this restores safety but costs performance, since full syncs flush/invalidate more cache lines per operation than partial ones. Removing or disabling highmem-dependent swiotlb configurations (for example by moving workloads to 64-bit kernels where the highmem branch is not exercised, or by booting with memory layouts that avoid highmem) removes the vulnerable path entirely, at the cost of losing the memory configuration or hardware support that required it. Because the issue requires local, authenticated access (PR:L) and the ability to drive DMA operations, restricting untrusted local users and unprivileged containers from reaching DMA-capable device nodes and drivers reduces the exposed attack surface, though it does not fix the underlying defect; no public exploit code has been identified at time of analysis, so prioritise patching on highmem/swiotlb systems and 32-bit platforms over emergency workarounds elsewhere.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The Linux kernel's swiotlb (software I/O TLB) provides bounce buffering for devices that cannot directly address all of system memory, notably on systems using highmem. swiotlb_bounce() derives a page frame number from the slot's recorded orig_addr and then advances orig_addr by tlb_offset to reach the address the caller requested, but the highmem branch mixes the two: the intra-page offset is computed from the adjusted address while the page itself comes from the pre-adjustment value, so once the adjustment crosses a page boundary the pair no longer describes a single location. The result is a wrong-page copy - one page below the target for a positive tlb_offset and one above for a negative one - meaning DMA_FROM_DEVICE writes device data over the wrong page and leaves the intended page stale, while DMA_TO_DEVICE reads from a page the mapping may not cover. The same flawed selection also drives the lowmem/highmem branch test, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phys_to_virt(). Non-zero tlb_offset only arises through partial syncs, i.e. dma_sync_single_range_for_cpu()/dma_sync_single_range_for_device() calls with unaligned or partial ranges; aligned full-buffer DMA keeps tlb_offset at zero and does not trigger the defect. The fix finalises orig_addr first, takes both offset and page from it, keeps pfn only in the branch that consumes it, and determines the highmem question directly from the final address (PhysHighMem()), matching the approach dma-debug already uses. No CWE identifier was assigned in the source data; the root-cause class is an incorrect address/page-frame pairing leading to out-of-range memory access and memory corruption in DMA buffer handling. CPE data identifies the affected software as linux:linux (cpe:2.3:a:linux:linux), i.e. the upstream kernel.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local-only kernel DMA trigger (AV:L); exploitation needs highmem config plus a page-crossing non-zero tlb_offset from partial syncs, so AC:H; low-privilege local trigger (PR:L) with high kernel-memory impact.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: use the adjusted address for the highmem page lookup
swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it.
Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero.
The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phys_to_virt().
Take both from orig_addr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does.
Executive ViewAI
A memory-handling flaw in the Linux kernel's swiotlb bounce-buffer code, CVE-2026-98254, can cause DMA copies to target the wrong physical page on systems using bounce buffering with highmem, typically 32-bit or large-memory builds. Exploitation requires authenticated local access and a specific DMA pattern, and a vendor patch is available. Because affected systems may suffer data corruption or unintended memory exposure, leadership should prioritize patching any qualifying Linux hosts, especially those in regulated or multi-tenant environments, while noting no public exploit has been identified at time of analysis.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB