CVE-2026-74280 in Linuxinfo

Summary

by MITRE • 08/15/2026

In the Linux kernel, the following vulnerability has been resolved:

crypto: marvell/octeontx - fix DMA cleanup using wrong loop index

The sg_cleanup path used list[i] instead of list[j] when unmapping DMA
buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 08/15/2026

The Linux kernel's cryptographic subsystem for Marvell OcteonTX platforms contains a critical logic error within its Direct Memory Access cleanup routine that compromises system stability and security posture during hardware initialization failures. This vulnerability resides in the scatter-gather list processing mechanism, specifically affecting the sg_cleanup path where DMA buffers are unmapped from device memory. The core technical flaw involves an incorrect loop index variable being utilized when iterating through the list of mapped entries to release resources. Instead of using the correct iterator j which tracks the current position for successful mappings, the code erroneously references index i, which typically serves as a counter or error tracking variable in this context. This mismatch leads to two distinct but equally damaging operational consequences: first, successfully mapped DMA buffers are not properly unmapped because the loop skips over them or accesses incorrect memory locations; second, entries that failed during mapping are repeatedly targeted for unmap operations despite never having been successfully allocated by the hardware driver.

From a technical perspective, this error represents a classic off-by-one or index confusion vulnerability often categorized under CWE-193 Off-by-One Error or more broadly as CWE-628 Function Call with Incorrectly Specified Arguments when considering the misuse of loop variables in resource management routines. The improper handling of DMA mappings means that kernel memory associated with these buffers remains reserved and inaccessible to other subsystems, leading to a gradual depletion of available physical memory resources over time. This is particularly dangerous in high-throughput cryptographic environments where many concurrent operations may trigger partial failures due to hardware constraints or transient errors. Each failed operation leaves behind leaked DMA mappings, creating a resource leak that accumulates with every subsequent crypto request until system performance degrades significantly or the kernel triggers an out-of-memory condition.

The operational impact of this vulnerability extends beyond simple memory leakage. Because the code repeatedly attempts to unmap entries that were never successfully mapped, it may trigger undefined behavior within the DMA API layer. Depending on the specific architecture and driver implementation, this could result in spurious error messages, kernel panics due to invalid address translations, or corruption of internal data structures maintained by the IOMMU subsystem. In a production environment running cryptographic workloads such as IPsec tunneling or disk encryption via Marvell OcteonTX hardware, these symptoms would manifest as intermittent system crashes, degraded network throughput, and unpredictable behavior during high-load scenarios where DMA mapping failures are more likely to occur due to resource contention.

This issue aligns with ATT&CK technique T1496 Resource Hijacking, specifically the sub-technique of exhausting resources through inefficient or malicious loops, although in this case the exploitation is unintentional rather than adversarial. The vulnerability highlights the importance of rigorous code review for low-level system drivers where memory management and hardware interaction are tightly coupled. Mitigation requires applying the upstream kernel patch that corrects the loop index variable from i to j within the sg_cleanup function. System administrators should ensure their Linux kernels are updated to versions containing this fix, particularly those targeting Marvell OcteonTX-based platforms. For organizations unable to immediately update, monitoring for signs of memory leaks in crypto-related processes and reviewing dmesg logs for DMA mapping errors can provide early detection indicators until a patched kernel is deployed.

Responsible

Linux

Reservation

08/15/2026

Disclosure

08/15/2026

Moderation

accepted

CPE

ready

EPSS

0.00210

KEV

no

Activities

very low

Sources

Do you need the next level of professionalism?

Upgrade your account now!