Answer in brief
CVE-2026-23067 records a Unknown severity vulnerability in iommu/io-pgtable-arm: fix size_t signedness bug in unmap path. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3318f7b5cefbff96b1bb49584ac38d2c9997a830 <41ec6988547819756fb65e94fc24f3e0dddf84ac || >=3318f7b5cefbff96b1bb49584ac38d2c9997a830 <374e7af67d9d9d6103c2cfc8eb32abfecf3a2fd8 | 41ec6988547819756fb65e94fc24f3e0dddf84ac, 374e7af67d9d9d6103c2cfc8eb32abfecf3a2fd8 |
| Linux/Linuxgeneric | 6.16 | Not reported |
Published upstream
Feb 4, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.