CVE-2026-23067: iommu/io-pgtable-arm: fix size_t signedness bug in unmap path
In the Linux kernel, the following vulnerability has been resolved:
iommu/io-pgtable-arm: fix size_t signedness bug in unmap path
__arm_lpae_unmap() returns size_t but was returning -ENOENT (negative
error code) when encountering an unmapped PTE. Since size_t is unsigned,
-ENOENT (typically -2) becomes a huge positive value (0xFFFFFFFFFFFFFFFE
on 64-bit systems).
This corrupted value propagates through the call chain:
__arm_lpae_unmap() returns -ENOENT as size_t
-> arm_lpae_unmap_pages() returns it
-> __iommu_unmap() adds it to iova address
-> iommu_pgsize() triggers BUG_ON due to corrupted iova
This can cause IOVA address overflow in __iommu_unmap() loop and
trigger BUG_ON in iommu_pgsize() from invalid address alignment.
Fix by returning 0 instead of -ENOENT. The WARN_ON already signals
the error condition, and returning 0 (meaning "nothing unmapped")
is the correct semantic for size_t return type. This matches the
behavior of other io-pgtable implementations (io-pgtable-arm-v7s,
io-pgtable-dart) which return 0 on error conditions.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel reliability flaw in ARM IOMMU page-table unmapping. An error value is returned through an unsigned size field, becoming a very large number. The described impact is a kernel BUG condition, which can crash affected systems.
Executive priority
Handle through normal kernel patch governance, with higher priority for ARM infrastructure where unexpected host crashes would affect availability commitments.
Technical view
__arm_lpae_unmap() returned -ENOENT despite a size_t return type. The value becomes a huge unsigned number, propagates through arm_lpae_unmap_pages() and __iommu_unmap(), corrupts IOVA arithmetic, and can trigger BUG_ON in iommu_pgsize(). The fix returns 0 for unmapped PTEs.
Likely exposure
Exposure appears limited to Linux systems using the ARM LPAE IOMMU page-table path in affected kernel builds. The bundle does not identify specific distributions, devices, cloud images, or default configurations.
Exploitation context
The source bundle does not report active exploitation, public exploit code, KEV listing, privilege requirements, or remote reachability. Treat this as a kernel crash risk until vendor advisories clarify exploitability.
Researcher notes
The evidence supports a signedness-to-overflow bug leading to BUG_ON, not memory disclosure or code execution. Affected-version detail is incomplete in the bundle, so distribution mapping requires vendor confirmation.
Mitigation direction
Identify Linux systems using affected kernel versions or referenced commit lineages.
Apply vendor kernel updates containing the linked stable fixes.
Prioritize ARM platforms using IOMMU-backed device mappings.
Check distribution advisories before making unsupported kernel changes.
Monitor kernel logs for related WARN_ON or BUG_ON events.
Validation and detection
Inventory kernel versions across ARM Linux assets.
Confirm whether affected hosts use the ARM LPAE IOMMU path.
Verify installed kernels include one of the linked stable commits.
Review crash logs for iommu_pgsize or __iommu_unmap BUG_ON traces.
Track vendor CVE status for distribution-specific fixed builds.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23067 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
3Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Feb 4, 2026, 16:07 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.