CVE-2026-31649

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix integer underflow in chain mode<br /> <br /> The jumbo_frm() chain-mode implementation unconditionally computes<br /> <br /> len = nopaged_len - bmax;<br /> <br /> where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is<br /> BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit()<br /> decides to invoke jumbo_frm() based on skb-&gt;len (total length including<br /> page fragments):<br /> <br /> is_jumbo = stmmac_is_jumbo_frm(priv, skb-&gt;len, enh_desc);<br /> <br /> When a packet has a small linear portion (nopaged_len len &gt; bmax), the<br /> subtraction wraps as an unsigned integer, producing a huge len value<br /> (~0xFFFFxxxx). This causes the while (len != 0) loop to execute<br /> hundreds of thousands of iterations, passing skb-&gt;data + bmax * i<br /> pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less<br /> SoCs (the typical deployment for stmmac), this maps arbitrary kernel<br /> memory to the DMA engine, constituting a kernel memory disclosure and<br /> potential memory corruption from hardware.<br /> <br /> Fix this by introducing a buf_len local variable clamped to<br /> min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then<br /> always safe: it is zero when the linear portion fits within a single<br /> descriptor, causing the while (len != 0) loop to be skipped naturally,<br /> and the fragment loop in stmmac_xmit() handles page fragments afterward.