CVE-2026-98803 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix rx Scatter-Gather support
When a received frame is larger than dma_buf_sz, the DMA scatters it across multiple RX descriptors (rx Scatter-Gather). The secondary RX buffer (sec_page) was only allocated and programmed when split-header (SPH) was active, so for regular frames buffer2 was neither allocated nor backed by a valid mapping. As soon as an incoming frame overflowed buffer1, the DMA wrote the overflow into the unmapped secondary-buffer address, triggering an SMMU translation fault on IOMMU-based platforms:
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x7f0011, cbfrsynra=0x1c90, cb=11 arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x1c90
arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1]
Enable scatter-gather for non-SPH frames on cores that can program an independent secondary RX buffer (GMAC4/XGMAC): allocate and mark buffer2 as valid in stmmac_init_rx_buffers() and stmmac_rx_refill(), and account for it in the buffer length computation. Legacy cores have no set_sec_addr op, so they keep buffer2 disabled.
Since buffer2 is handed to the DMA at page offset 0, the page pool sync window is widened to cover both buffers in every mode: offset is set to 0 and max_len to dma_buf_sz + stmmac_rx_offset().
The FCS can straddle the buffer1/buffer2 boundary and a descriptor boundary, so it is now stripped from the tail of the assembled frame with pskb_trim() instead of from a single buffer, avoiding an unsigned underflow for frames that overflow a buffer by 1..3 bytes. For single-buffer frames the XDP program must not see the FCS, so it is removed from the XDP buffer before the program runs.
Native XDP currently only supports single-buffer (linear) frames. An oversized frame accepted by the MAC (jumbo enabled) is received via buffer2; the XDP program only sees buffer1, so on a TX/REDIRECT verdict the frame is forwarded truncated. XDP multi-buffer support to handle this case is planned as a follow-up.
AF_XDP zero-copy RX is not covered by this change: a ZC queue still programs buffer2 at DMA address 0 (and XGMAC has no buffer2-valid bit), so an oversized frame overflowing buffer1 can still trigger the same SMMU translation fault. Handling is planned as a follow-up.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel network driver for Synopsys DesignWare MAC controllers, specifically stmmac, contained a critical vulnerability related to Receive Scatter-Gather (RX SG) support on IOMMU-based platforms. The core issue stems from improper handling of received Ethernet frames that exceed the size of the primary DMA buffer. When such an oversized frame arrives, the hardware is designed to scatter it across multiple RX descriptors using secondary buffers. However, prior to this fix, the secondary RX buffer was only allocated and programmed when Split Header (SPH) mode was active. For regular non-SPH frames that overflowed the first buffer, the system failed to allocate or map a valid memory region for the second buffer. Consequently, the DMA engine attempted to write the overflowing portion of the packet into an unmapped address space, typically zero, which triggered System Memory Management Unit (SMMU) translation faults on ARM-based systems utilizing IOMMU hardware. This fault manifests as an unhandled context error with specific status registers indicating a format two translation fault at a virtual address of zero, effectively causing a denial of service by disrupting network connectivity and potentially crashing the system depending on kernel panic settings for such faults.
The technical resolution involves enabling scatter-gather functionality for non-SPH frames on hardware cores capable of programming an independent secondary RX buffer, specifically GMAC4 and XGMAC variants. The fix ensures that in functions responsible for initializing receive buffers like stmmac_init_rx_buffers() and refilling them via stmmac_rx_refill(), the second buffer is properly allocated and marked as valid. This adjustment also requires accounting for this additional buffer during length computations to ensure data integrity. Legacy cores lacking a set_sec_addr operation remain unaffected by these changes, continuing to operate with buffer2 disabled to maintain stability on older hardware. Furthermore, because the secondary buffer is handed to the DMA at page offset zero, the synchronization window within the page pool mechanism was widened to encompass both buffers in every operational mode. This involves setting the offset to zero and adjusting the maximum length parameter to include dma_buf_sz plus stmmac_rx_offset(), ensuring that cache coherency operations cover all relevant memory regions involved in packet reception.
Beyond the immediate DMA mapping issue, the patch addresses several edge cases related to Frame Check Sequence (FCS) handling and Extended Data Path (XDP) integration. The FCS can straddle the boundary between buffer1 and buffer2 as well as descriptor boundaries. To prevent unsigned integer underflows that could occur when trimming frames that overflow a buffer by one to three bytes, the implementation now strips the FCS from the tail of the assembled frame using pskb_trim() rather than attempting removal from a single buffer. For scenarios involving XDP programs processing single-buffer frames, the FCS is explicitly removed before the program executes to ensure compliance with expected packet structures and prevent potential logic errors within user-space or kernel-space eBPF applications. This careful handling of metadata ensures that network stack consumers receive clean packets without trailing checksum data that could interfere with protocol parsing.
The update also clarifies limitations regarding Native XDP support, noting that current implementations only handle single-buffer linear frames. When an oversized frame is accepted by the MAC due to jumbo frame settings being enabled, it is received via buffer2, but the XDP program only observes buffer1. Consequently, if a TX or REDIRECT verdict is applied, the forwarded frame will be truncated, potentially losing critical data at the end of the packet. While multi-buffer support for XDP is planned as a future enhancement to fully resolve this truncation issue, the current fix stabilizes the underlying memory management errors that could cause system crashes. Additionally, AF_XDP zero-copy RX remains outside the scope of this patch because such queues still program buffer2 at DMA address zero on architectures like XGMAC which lack a specific valid bit for buffer2. This means oversized frames in zero-copy scenarios can still trigger SMMU translation faults, indicating that further development is required to secure high-performance packet processing paths against similar memory safety violations.
From a vulnerability classification perspective, this issue aligns with CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer and CWE-400 Uncontrolled Resource Consumption due to improper handling of large inputs leading to resource exhaustion or faults. In terms of attack vectors, while primarily causing denial of service through system instability rather than direct code execution, it relates to ATT&CK technique T1498 Network Denial of Service where an attacker could potentially flood the network with oversized packets to trigger these translation faults and disrupt availability on affected embedded systems. Mitigation strategies involve applying this kernel patch immediately for all devices running affected stmmac drivers on ARM IOMMU platforms, ensuring that firmware or bootloader configurations do not enable jumbo frames unless strictly necessary and monitored, and verifying that XDP programs are updated if they rely on specific buffer assumptions to avoid truncation issues in production environments.