Description

In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-15T13:17:54.453Z",
  "pubdate": "2026-08-15T13:17:54.453Z",
  "executiveSummary": "An information leak and resource management vulnerability exists within the Linux kernel igbvf network driver TX DMA error cleanup routine.\nThe vulnerability type is a resource leak resulting from incorrect index bookkeeping during DMA mapping failure handling.\nThe impact includes kernel memory resource exhaustion and potential system instability due to leaked DMA mappings.\nAffected systems include Linux kernel installations utilizing the igbvf driver.\nRisk implications center on kernel-level resource degradation, potentially leading to denial of service conditions.\nAttacker capabilities involve triggering error conditions during transmission buffer mapping, typically requiring local execution context or network traffic generation that induces mapping failures.\nExploitation requirements include conditions where TX buffer mapping encounters a failure after initial successful mappings for a given socket buffer.",
  "technicalDetails": "The vulnerable component is the igbvf driver within the Linux kernel, specifically within its TX DMA error cleanup logic.\nThe root cause of the vulnerability stems from an off-by-one error introduced by decrementing the count variable before a while loop in the dma_error handler.\nBecause the count variable is incremented prior to each fragment mapping, it accurately reflects the total number of successfully mapped buffers requiring unmapping when dma_error is reached.\nPrematurely decrementing count invalidates this tracking mechanism, causing the driver to skip unmapping the head DMA mapping whenever any preceding mapping was successful prior to an unsuccessful mapping.\nConsequently, exactly one DMA mapping leaks during such error sequences.\nThe attack flow involves the driver attempting to map TX buffers for an skb, successfully mapping one or more fragments or the head, and subsequently encountering a mapping error.\nUpon reaching the dma_error label, the flawed cleanup loop fails to release all previously acquired DMA mappings due to the off-by-one discrepancy.\nThis behavior leads to persistent leakage of DMA mapping resources every time the specific error condition is triggered.\nAuthentication and privilege requirements depend on the system context required to trigger network driver TX operations and associated mapping failures.\nThe payload behavior is passive in terms of execution, manifesting purely as a resource leak rather than arbitrary code execution.\nPost-exploitation impact is limited to kernel resource exhaustion and degraded system reliability over time."
}