CVE-2026-23033

What it actually does

Resource leak of a dma_pool object allocated by dma_pool_create() when subsequent calls to dma_async_device_register() or of_dma_controller_register() fail during omap-dma driver probe, leaving the pool allocated without a matching dma_pool_destroy().

Why it matters to the business

Repeated probe failures on affected Linux systems can gradually exhaust kernel memory and DMA resources, potentially leading to degraded performance, allocation failures for other drivers, or eventual system instability in environments with frequent module reloads or hardware initialization errors.

How an attack unfolds

An attacker with the ability to induce repeated probe failures (for example through crafted device tree entries, hardware faults, or module unload/reload sequences) could trigger the leak path, slowly consuming kernel resources without triggering any explicit error handling or logging beyond the initial failure.

How to fix it

Update the Linux kernel to the commit 8d66cb05b8b76396387a7b3a91f9284225c87f04 or later that adds the missing dma_pool_destroy() calls in both error paths. Rebuild and deploy the fixed kernel image, then reboot affected systems. For systems that cannot be immediately updated, limit conditions that cause repeated probe failures by stabilizing hardware configuration and device tree entries.

How to confirm the fix worked

Inspect the omap-dma source for the presence of dma_pool_destroy() immediately after the failure returns from dma_async_device_register() and of_dma_controller_register(); verify the running kernel contains commit 8d66cb05b8b76396387a7b3a91f9284225c87f04 via kernel version or git log; monitor kernel memory statistics for stabilization after probe error injection tests.

Typical attack path

1. Gain local access or ability to influence device enumeration and driver probing on a Linux system using omap-dma.
2. Trigger repeated failure conditions in dma_async_device_register() or of_dma_controller_register() during probe.
3. Repeat the failure sequence to accumulate leaked dma_pool allocations without corresponding destruction.
4. Observe gradual kernel memory pressure or resource exhaustion affecting system stability.

How to detect it

Review kernel logs for repeated omap-dma probe failures followed by resource warnings; correlate with memory allocation counters or slab statistics showing growth in dma_pool objects without corresponding frees; examine dmesg or syslog for dma_pool_create() success without a matching destroy in error traces.

What your security team should do

• Prioritize kernel updates containing commit 8d66cb05b8b76396387a7b3a91f9284225c87f04 on all systems using omap-dma within the next maintenance window.
• Audit device tree and hardware configurations to reduce the likelihood of probe failures that exercise the leaky paths.
• Add kernel memory usage and dma_pool allocation monitoring to detect anomalous growth after driver reload events.
• Include the fixed commit identifier in automated kernel build and deployment pipelines to prevent regression.