CVE-2026-43224: Linux Kernel Information Disclosure Flaw

CVE-2026-43224 Overview

CVE-2026-43224 is a memory leak vulnerability in the Linux kernel's io_uring/zcrx (zero-copy receive) subsystem. The flaw resides in the io_zcrx_map_area() function, which fails to release an initialised scatter-gather table when io_populate_area_dma() returns an error. The error path is gated by an !is_mapped check that prevents the cleanup from executing, leaving the sgtable allocated. The condition only triggers on PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA machines, making it a narrow but real resource leak in the kernel networking I/O path.

Critical Impact

Repeated mapping failures can leak kernel sgtable allocations, contributing to resource exhaustion on affected 32-bit architectures with 64-bit DMA support.

Affected Products

• Linux kernel versions containing the io_uring/zcrx zero-copy receive implementation
• Systems built with PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA
• Distributions tracking mainline and stable kernel branches prior to the referenced fix commits

Discovery Timeline

• 2026-05-06 - CVE-2026-43224 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43224

Vulnerability Analysis

The io_uring subsystem provides high-performance asynchronous I/O, and the zcrx component implements zero-copy receive paths backed by page pools. During area registration, io_zcrx_map_area() allocates and initialises a scatter-gather table, then calls io_populate_area_dma() to set up DMA mappings for the underlying pages.

When io_populate_area_dma() fails, control transfers to the cleanup path. That path conditionally tears down resources based on the is_mapped flag. Because mapping never completed successfully, is_mapped remains false and the cleanup branch responsible for freeing the sgtable is skipped. The allocated sg_table therefore persists past the function's lifetime without an owner, producing a kernel memory leak.

The fault only manifests on architectures defined by PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA, where the kernel must perform additional DMA address handling. Although the failure path is described as unlikely, repeated triggering by an attacker with the ability to register zcrx areas can degrade kernel memory availability over time.

Root Cause

The root cause is incorrect error-path logic in io_zcrx_map_area(). The !is_mapped gate excludes the sgtable release call from running when io_populate_area_dma() fails before mapping completes, even though the table was already initialised earlier in the function.

Attack Vector

Exploitation requires local access to the affected host with permissions to invoke io_uring registration ioctls against zcrx areas, and the host must be a PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA build. Repeatedly inducing io_populate_area_dma() failures leaks kernel scatter-gather tables, leading to a denial-of-service style resource exhaustion. The flaw does not provide direct code execution or privilege escalation.

The vulnerability is described in prose because no public proof-of-concept code is referenced. Refer to the upstream patch commits for the precise diff and behavioural change: Kernel Patch Commit a983aae39776, Kernel Patch Commit ef075c1464ac, and Kernel Patch Commit f1ae40332431.

Detection Methods for CVE-2026-43224

Indicators of Compromise

• Gradual decline in available kernel memory on long-running hosts that use io_uring zero-copy receive
• Repeated io_uring_register() calls targeting zcrx areas from a single user-space process
• dmesg warnings or page allocator pressure messages tied to scatter-gather or DMA mapping failures

Detection Strategies

• Audit running kernel versions against the fix commits a983aae39776, ef075c1464ac, and f1ae40332431 to identify unpatched hosts.
• Track slabinfo growth for sg_table-related caches over time on hosts using io_uring zcrx workloads.
• Correlate kernel log entries indicating DMA mapping errors with unexpected memory consumption trends.

Monitoring Recommendations

• Enable kernel memory accounting and alert on sustained growth of unreclaimable slab memory.
• Monitor io_uring syscall usage per process, especially IORING_REGISTER_* operations against network areas.
• Forward kernel logs to a centralised analytics platform to flag recurring io_populate_area_dma failures.

How to Mitigate CVE-2026-43224

Immediate Actions Required

• Identify hosts built with PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA and prioritise them for kernel updates.
• Apply the stable kernel update that includes the upstream fix commits referenced by this CVE.
• Restrict io_uring use through kernel.io_uring_disabled or seccomp policies for untrusted workloads until patches are deployed.

Patch Information

The fix removes the incorrect !is_mapped gate so that an initialised sgtable is freed when io_populate_area_dma() fails. Apply the patches from the upstream stable tree: Kernel Patch Commit a983aae39776, Kernel Patch Commit ef075c1464ac, and Kernel Patch Commit f1ae40332431. Distribution-specific kernel updates that incorporate these commits should be installed once available.

Workarounds

• Disable io_uring for unprivileged users by setting kernel.io_uring_disabled=2 via sysctl where workloads permit.
• Avoid building or deploying kernels with PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA configurations on exposed systems until patched.
• Use seccomp filters to block io_uring_setup and io_uring_register syscalls for workloads that do not require them.

# Configuration example
# Disable io_uring for unprivileged users until the patched kernel is deployed
sudo sysctl -w kernel.io_uring_disabled=2
echo 'kernel.io_uring_disabled = 2' | sudo tee /etc/sysctl.d/99-io_uring.conf

# Verify the running kernel against the fix commits
uname -r
zcat /proc/config.gz | grep -E 'IO_URING|PAGE_POOL'