In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TX descriptor…

Why it is Amber

• CVSS 7.0 high
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/09c30547da2c45bb79f7d3adffc860af332c2d42
• https://git.kernel.org/stable/c/5e38d732ec67a5b1f9a56e6c73add480c4b6030a
• https://git.kernel.org/stable/c/65820fc743eae322f7f94f6a64d07861211d4b21
• https://git.kernel.org/stable/c/c28175220f808c867d5618de8ecc6dbcc815c773
• https://git.kernel.org/stable/c/ffa6d2481bc1c87f822ecd626561484e4ee24cef

Original description

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TX descriptor availability check for TSO traffic stmmac_tso_xmit() estimates the number of free TX descriptors required by a TSO skb as: (skb->len - proto_hdr_len) / TSO_MAX_BUFF_SIZE + 1 which assumes the payload is split into TSO_MAX_BUFF_SIZE chunks. This underestimates the descriptors actually consumed by stmmac_tso_allocator(), since each fragment is mapped individually and so it needs at least one descriptor regardless of its size. Moreover, one descriptor is used for the L2/L3/L4 headers and, when the MSS changes, one more is consumed for the MSS context descriptor. For a highly fragmented TSO skb the check can therefore pass even when the ring has too few free slots. stmmac_tso_allocator() then writes past the available descriptors, overwriting descriptors still owned by the DMA engine, corrupting the TX ring. Add stmmac_tso_get_num_desc() to compute the exact number of descriptors needed for the header, the linear payload and each fragment, plus the MSS context descriptor when required, and use it in the availability check.