Status: UPDATED | Advisory ID: CVE-2026-53009
| CVE | CVE-2026-53009 |
| CVSS Score / Version | |
| Updated | 2026-10-15 |
| CVSS Vector | |
| CVSS Prose | |
| Affected products | |
| Classified as | |
| Exploitation prediction (EPSS) |
| Vendor | Product | Affected Versions | Patch Status |
|---|---|---|---|
| Red Hat | Enterprise Linux | ||
| Linux | Linux Kernel | ||
| Red Hat | Red Hat Enterprise Linux 10 | ||
| Red Hat | Red Hat Enterprise Linux 8 | ||
| Red Hat | Red Hat Enterprise Linux 9 | ||
| Red Hat | Red Hat Enterprise Linux 7 |
| Subsystems | OT Supporting Infrastructure |
| Sectors | All Sectors |
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. (NVD)
Monitor Red Hat's and Linux's web pages for any future patch releases.
| Source | Reference |
|---|---|
| NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-53009 |
| CVE | https://www.cve.org/CVERecord?id=CVE-2026-53009 |