Описание
ELSA-2026-54246: kernel security update (MODERATE)
[4.18.0-553.154.1]
- Update Oracle Linux certificates (Kevin Lyons)
- Disable signing for aarch64 (Ilya Okomin)
- Oracle Linux RHCK Module Signing Key was added to the kernel trusted keys list (olkmod_signing_key.pem) [Orabug: 29539237]
- Update x509.genkey [Orabug: 24817676]
- Conflict with shim-ia32 and shim-x64 <= 15.3-1.0.3
- Remove upstream reference during boot (Kevin Lyons) [Orabug: 34750652]
- Add new Oracle Linux Driver Signing (key 1) certificate [Orabug: 37985772]
[4.18.0-553.155.1]
- udf: fix partition descriptor append bookkeeping (Ravi Singh) [RHEL-179571] {CVE-2026-45991}
- ice: fix double-free of tx_buf skb (Michal Schmidt) [RHEL-192193] {CVE-2026-53009}
Обновленные пакеты
Oracle Linux 8
Oracle Linux aarch64
kernel-tools-libs-devel
4.18.0-553.155.1.el8_10
bpftool
4.18.0-553.155.1.el8_10
kernel-cross-headers
4.18.0-553.155.1.el8_10
kernel-headers
4.18.0-553.155.1.el8_10
kernel-tools
4.18.0-553.155.1.el8_10
kernel-tools-libs
4.18.0-553.155.1.el8_10
perf
4.18.0-553.155.1.el8_10
python3-perf
4.18.0-553.155.1.el8_10
Oracle Linux x86_64
kernel-tools-libs-devel
4.18.0-553.155.1.el8_10
bpftool
4.18.0-553.155.1.el8_10
kernel
4.18.0-553.155.1.el8_10
kernel-abi-stablelists
4.18.0-553.155.1.el8_10
kernel-core
4.18.0-553.155.1.el8_10
kernel-cross-headers
4.18.0-553.155.1.el8_10
kernel-debug
4.18.0-553.155.1.el8_10
kernel-debug-core
4.18.0-553.155.1.el8_10
kernel-debug-devel
4.18.0-553.155.1.el8_10
kernel-debug-modules
4.18.0-553.155.1.el8_10
kernel-debug-modules-extra
4.18.0-553.155.1.el8_10
kernel-devel
4.18.0-553.155.1.el8_10
kernel-doc
4.18.0-553.155.1.el8_10
kernel-headers
4.18.0-553.155.1.el8_10
kernel-modules
4.18.0-553.155.1.el8_10
kernel-modules-extra
4.18.0-553.155.1.el8_10
kernel-tools
4.18.0-553.155.1.el8_10
kernel-tools-libs
4.18.0-553.155.1.el8_10
perf
4.18.0-553.155.1.el8_10
python3-perf
4.18.0-553.155.1.el8_10
Связанные CVE
Связанные уязвимости
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...
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...
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
