CVE-2026-23067: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-23067 Overview

A signedness bug has been identified in the Linux kernel's IOMMU io-pgtable-arm implementation. The __arm_lpae_unmap() function returns a size_t type but was incorrectly returning -ENOENT (a negative error code) when encountering an unmapped PTE. Since size_t is an unsigned type, the negative value -ENOENT (typically -2) becomes a large positive value (0xFFFFFFFFFFFFFFFE on 64-bit systems), causing corruption in the IOVA address calculations.

Critical Impact

This vulnerability can cause IOVA address overflow in the __iommu_unmap() loop and trigger BUG_ON in iommu_pgsize() due to invalid address alignment, potentially leading to kernel crashes and system instability.

Affected Products

• Linux Kernel (io-pgtable-arm IOMMU implementation)
• Systems using ARM LPAE page table format
• Devices with ARM-based IOMMU hardware

Discovery Timeline

• 2026-02-04 - CVE-2026-23067 published to NVD
• 2026-02-05 - Last updated in NVD database

Technical Details for CVE-2026-23067

Vulnerability Analysis

The vulnerability exists in the IOMMU io-pgtable-arm subsystem of the Linux kernel. The core issue is a type mismatch where __arm_lpae_unmap() is defined to return size_t (an unsigned integer type representing memory sizes) but was returning -ENOENT, which is a negative error code. This fundamental type confusion creates a dangerous situation where error handling becomes corrupted value propagation.

When an unmapped PTE is encountered, the function returns -ENOENT instead of a valid size value. On 64-bit systems, this negative value is interpreted as an extremely large unsigned value (0xFFFFFFFFFFFFFFFE). This corrupted value then propagates through the call chain, causing the IOVA address to overflow when added in __iommu_unmap(), ultimately triggering a BUG_ON assertion in iommu_pgsize() due to the resulting invalid address alignment.

Root Cause

The root cause is improper return type handling in the __arm_lpae_unmap() function. The function signature declares a size_t return type, but the implementation was returning a signed negative error code (-ENOENT). This violates the semantic contract of the function, as size_t values should represent non-negative sizes. The implicit conversion from signed to unsigned caused the error value to become a massive positive integer, corrupting subsequent calculations.

The proper fix returns 0 instead of -ENOENT, indicating that nothing was unmapped. This approach maintains type safety while preserving error signaling through the existing WARN_ON mechanism. This fix aligns with the behavior of other io-pgtable implementations (io-pgtable-arm-v7s and io-pgtable-dart) which already return 0 on error conditions.

Attack Vector

The vulnerability is triggered through the IOMMU unmap path when the kernel attempts to unmap a PTE that is not currently mapped. The corrupted return value causes the following chain of events:

1. __arm_lpae_unmap() returns -ENOENT cast to size_t, becoming 0xFFFFFFFFFFFFFFFE
2. arm_lpae_unmap_pages() passes this corrupted value up the call stack
3. __iommu_unmap() adds this value to the IOVA address, causing overflow
4. iommu_pgsize() receives an invalid, misaligned address and triggers BUG_ON

This results in a kernel panic or system crash. While the attack vector is unknown and there is no known active exploitation, this vulnerability could potentially be triggered by malformed DMA operations or driver bugs that attempt to unmap non-existent mappings.

Detection Methods for CVE-2026-23067

Indicators of Compromise

• Kernel panic messages referencing iommu_pgsize() or BUG_ON assertions
• System logs showing IOMMU-related crashes or unexpected behavior
• Debug traces indicating corrupted IOVA addresses with extremely large values
• Kernel oops messages in the __iommu_unmap() code path

Detection Strategies

• Monitor kernel logs for IOMMU subsystem errors and BUG_ON triggers
• Implement kernel debugging with IOMMU tracing enabled to catch address corruption
• Use static analysis tools to identify similar signedness issues in kernel code
• Enable kernel address sanitizer (KASAN) for runtime memory corruption detection

Monitoring Recommendations

• Configure persistent kernel logging to capture crash dumps for forensic analysis
• Set up automated alerting for kernel panic events related to IOMMU operations
• Monitor system stability metrics on ARM-based systems with IOMMU enabled
• Review kernel audit logs for unusual DMA mapping/unmapping patterns

How to Mitigate CVE-2026-23067

Immediate Actions Required

• Apply the official kernel patch from the stable kernel tree immediately
• Reboot systems after patching to ensure the fix is active in the running kernel
• Prioritize patching on ARM-based systems with active IOMMU usage
• Review and test any custom IOMMU-dependent drivers for similar issues

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix modifies __arm_lpae_unmap() to return 0 instead of -ENOENT when encountering an unmapped PTE, maintaining proper size_t semantics while preserving error signaling through the existing WARN_ON mechanism.

Official patches are available from the kernel.org stable tree:

• Kernel Git Commit 374e7af67d9d
• Kernel Git Commit 41ec69885478

Workarounds

• If immediate patching is not possible, consider disabling IOMMU on affected systems temporarily (reduces security posture)
• Implement additional monitoring for kernel panics to detect exploitation attempts
• Avoid workloads that may trigger frequent DMA unmapping operations until patched
• Consider using alternative virtualization strategies that do not rely on ARM LPAE IOMMU

# Check current kernel version for vulnerability status
uname -r

# Verify IOMMU is enabled (for identifying affected systems)
dmesg | grep -i iommu

# Monitor for IOMMU-related kernel issues
journalctl -k | grep -E "(iommu|BUG_ON|lpae)"