In the Linux kernel, the following vulnerability has been resolved: ice: fix double-free of tx_buf skb If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time. The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path. The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch. I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN. I looked for similar bugs in related Intel drivers and did not find any.

A flaw was found in the Linux kernel's ice network driver. An error in the driver's handling of network packet transmission, specifically when ice_tso() or ice_tx_csum() functions fail, can lead to a double-free of a network buffer (skb). This occurs because a transmit buffer (tx_buf) may still point to an already freed buffer. If the network interface is subsequently brought down, this double-free can be triggered, potentially leading to a system crash or denial of service (DoS).

A double free can occur in the Intel ice TX path when ice_xmit_frame_ring() stores an skb in the first tx_buf and marks it as ICE_TX_BUF_SKB, then an ice_tso() or ice_tx_csum() failure drops and frees the skb while the tx_buf still points to it. If no later packet overwrites that descriptor before the interface or TX ring is cleaned, ice_clean_tx_ring() can free the same skb again. For the CVSS the PR:L because a local user or process that can transmit traffic through an affected ice interface may reach the TX path, although reliable triggering also depends on forcing an offload error and a later cleanup window. To mitigate this issue, prevent module ice from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically. Red Hat Enterprise Linux 10 Affected kernel Red Hat Enterprise Linux 6 Not affected kernel Red Hat Enterprise Linux 7 Affected kernel Red Hat Enterprise Linux 7 Affected kernel-rt Red Hat Enterprise Linux 8 Affected kernel Red Hat Enterprise Linux 8 Affected kernel-rt Red Hat Enterprise Linux 9 Affected kernel Red Hat Enterprise Linux 9 Affected kernel-rt https://www.cve.org/CVERecord?id=CVE-2026-53009 https://nvd.nist.gov/vuln/detail/CVE-2026-53009 https://lore.kernel.org/linux-cve-announce/2026062449-CVE-2026-53009-4fef@gregkh/T