]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
ice: fix double-free of tx_buf skb
authorMichal Schmidt <mschmidt@redhat.com>
Fri, 17 Apr 2026 00:53:28 +0000 (17:53 -0700)
committerJakub Kicinski <kuba@kernel.org>
Sat, 18 Apr 2026 19:01:33 +0000 (12:01 -0700)
commit1a303baa715e6b78d6a406aaf335f87ff35acfcd
treed3fd0569c80c1bdfd31e7c8e4965fbcc02e97828
parent9aab1c3d7299285e2569cbc0ed5892d631a241b2
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.

Fixes: d76a60ba7afb ("ice: Add support for VLANs and offloads")
Assisted-by: Claude:claude-4.6-opus-high Cursor
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-4-686c33c9828d@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
drivers/net/ethernet/intel/ice/ice_txrx.c