CVE-2026-53009

What it actually does

This flaw is a double-free bug in the Linux kernel Intel Ethernet Connection E800 Series "ice" network driver transmit path. If transmit segmentation offload or checksum preparation fails in ice_xmit_frame_ring(), the driver frees the socket buffer but leaves the transmit buffer descriptor marked as still owning a valid skb. If the interface is then brought down before another packet overwrites that descriptor, ice_clean_tx_ring() can free the same skb again. This is kernel memory corruption that can plausibly cause a kernel crash, denial of service, or undefined kernel behavior; reliable privilege escalation has not been demonstrated from the provided information.

Why it matters to the business

Systems using affected Linux kernels with Intel ice-supported network adapters may be vulnerable to crashes or instability when specific transmit error paths are triggered and the interface is reset or shut down. Because this is in a network driver, the most likely operational impact is host outage, network service disruption, failover events, or degraded availability of workloads dependent on those interfaces. Current public exploitation signals are low: EPSS is 0.00129, it is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no mature public exploit is indicated; however, kernel memory corruption should still be remediated during normal kernel update cycles, especially on high-availability hosts using the ice driver.

How an attack unfolds

An attacker would first need a way to influence traffic transmitted through a vulnerable Intel ice network interface or local ability to generate crafted outbound traffic. The attacker attempts to cause the driver transmit path to enter ice_tso() or ice_tx_csum() failure handling, leaving a transmit buffer entry pointing to an skb that has already been freed. The attacker then needs the interface to be brought down, reset, or otherwise cleaned before another transmit operation overwrites the stale descriptor. During transmit ring cleanup, the driver can free the same skb a second time, corrupting kernel memory and potentially causing a kernel panic. In practical terms, exploitation is likely environment-dependent and timing-sensitive, and there is no indication of public weaponization at this time.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the upstream ice driver fix resetting the tx_buf type to ICE_TX_BUF_EMPTY on the error path. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories for the deployed distribution and kernel stream. Prioritize hosts that use Intel E800/ice-supported network adapters, especially production systems where host crashes or network outages have high impact. If immediate patching is not possible, reduce risk by minimizing unnecessary interface resets, avoiding unstable driver/firmware combinations, disabling unused ice interfaces, and considering temporary migration of critical workloads away from exposed hosts. Where operationally acceptable, disabling offload features such as TSO or checksum offload may reduce exposure to the vulnerable path, but this should be validated for performance impact and should not be treated as a complete fix.

How to confirm the fix worked

Confirm exposure by checking whether the system is running the ice driver and whether the active kernel contains the vendor fix. Use commands such as uname -a, modinfo ice, ethtool -i <interface>, and the distribution package manager to identify the kernel and driver build. Validate remediation by confirming the installed kernel version is at or above the vendor-fixed release and rebooting into that kernel. For source-based validation, verify that the ice transmit error path clears the transmit buffer state to ICE_TX_BUF_EMPTY after skb free handling. After patching, monitor dmesg, journalctl -k, and kernel crash logs for recurrence of KASAN double-free reports or call traces involving ice_xmit_frame_ring(), ice_clean_tx_ring(), or ice_unmap_and_free_tx_buf().

Typical attack path

1. Identify a Linux host using the Intel ice kernel driver for an affected network interface.
2. Generate or induce outbound network traffic that exercises transmit segmentation offload or checksum offload handling.
3. Trigger an error path in ice_tso() or ice_tx_csum() so the skb is freed while the transmit buffer descriptor remains marked valid.
4. Cause or wait for the interface to be brought down, reset, or cleaned before another packet transmission overwrites the stale tx_buf entry.
5. Trigger ice_clean_tx_ring() cleanup, causing ice_unmap_and_free_tx_buf() to free the same skb again.
6. Leverage the resulting kernel memory corruption primarily to crash the host or disrupt networking; more advanced impact would require additional exploit development.

How to detect it

Look for evidence of kernel memory corruption or crashes involving the ice driver transmit cleanup path. Primary log sources are dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore analysis, crash utility output, EDR kernel panic telemetry, and hypervisor management logs showing guest or host resets. Search for KASAN, KFENCE, BUG, slab, use-after-free, double-free, or general protection fault messages with stack traces containing ice_xmit_frame_ring(), ice_tso(), ice_tx_csum(), ice_clean_tx_ring(), or ice_unmap_and_free_tx_buf(). Also correlate suspicious timing: outbound traffic bursts or offload-related transmit errors followed by interface down/reset events and then a kernel panic. There are no reliable network-only indicators for exploitation, and a crash alone does not prove malicious exploitation because the failure path may be triggered by normal errors, driver issues, or testing. If available, preserve vmcores and inspect whether the faulting stack includes the ice transmit ring cleanup path and whether the same skb or tx_buf appears to have been freed twice.

• KASAN: double-free
• BUG: KASAN
• double-free
• ice_xmit_frame_ring
• ice_clean_tx_ring
• ice_unmap_and_free_tx_buf
• ice_tso
• ice_tx_csum
• ICE_TX_BUF_SKB
• ICE_TX_BUF_EMPTY
• general protection fault
• kernel BUG
• skb_release_data
• kfree_skb
• freeing skb
• slab corruption
• detected corruption in memory
• driver: ice
• ice

What your security team should do

• Inventory Linux systems using the Intel ice network driver with ethtool -i, modinfo, configuration management, or EDR telemetry.
• Prioritize kernel updates for production, virtualization, storage, database, and network-intensive hosts using ice-supported Intel adapters.
• Track the relevant Linux distribution or appliance vendor advisory because exact fixed package versions vary by kernel stream and were not provided here.
• Reboot systems after kernel update and verify they are running the fixed kernel, not merely that the package is installed.
• Review recent kernel logs and crash dumps for double-free, KASAN, slab corruption, or kernel panic traces involving the ice driver.
• If patching must be delayed, consider disabling unused ice interfaces, reducing interface reset automation, and evaluating temporary offload disablement as a risk-reduction measure.
• Because this issue is not currently KEV-listed and has low EPSS, handle as prioritized maintenance unless local crash evidence, exposure on critical hosts, or vendor guidance warrants emergency remediation.