Описание
ELSA-2026-49212: kernel security update (IMPORTANT)
[5.14.0-687.33.1]
- Disable UKI signing [Orabug: 36571828]
- 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.5]
- Remove upstream reference during boot (Kevin Lyons) [Orabug: 34729535]
- Add Oracle Linux IMA certificates
- Add new Oracle Linux Driver Signing (key 1) certificate [Orabug: 37985764]
[5.14.0-687.33.1]
- net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle (CKI Backport Bot) [RHEL-213299] {CVE-2026-64530}
- ipc: limit next_id allocation to the valid ID range (Rafael Aquini) [RHEL-188214] {CVE-2026-52923}
[5.14.0-687.32.1]
- tipc: fix double-free in tipc_buf_append() (CKI Backport Bot) [RHEL-192184] {CVE-2026-52993}
Обновленные пакеты
Oracle Linux 9
Oracle Linux aarch64
kernel-cross-headers
5.14.0-687.33.1.el9_8
kernel-tools-libs-devel
5.14.0-687.33.1.el9_8
libperf
5.14.0-687.33.1.el9_8
kernel-headers
5.14.0-687.33.1.el9_8
perf
5.14.0-687.33.1.el9_8
python3-perf
5.14.0-687.33.1.el9_8
rtla
5.14.0-687.33.1.el9_8
rv
5.14.0-687.33.1.el9_8
kernel-tools
5.14.0-687.33.1.el9_8
kernel-tools-libs
5.14.0-687.33.1.el9_8
Oracle Linux x86_64
kernel-debug-devel
5.14.0-687.33.1.el9_8
kernel-debug-devel-matched
5.14.0-687.33.1.el9_8
kernel-devel
5.14.0-687.33.1.el9_8
kernel-devel-matched
5.14.0-687.33.1.el9_8
kernel-doc
5.14.0-687.33.1.el9_8
kernel-headers
5.14.0-687.33.1.el9_8
perf
5.14.0-687.33.1.el9_8
python3-perf
5.14.0-687.33.1.el9_8
rtla
5.14.0-687.33.1.el9_8
rv
5.14.0-687.33.1.el9_8
kernel-cross-headers
5.14.0-687.33.1.el9_8
kernel-tools-libs-devel
5.14.0-687.33.1.el9_8
libperf
5.14.0-687.33.1.el9_8
kernel
5.14.0-687.33.1.el9_8
kernel-abi-stablelists
5.14.0-687.33.1.el9_8
kernel-core
5.14.0-687.33.1.el9_8
kernel-debug
5.14.0-687.33.1.el9_8
kernel-debug-core
5.14.0-687.33.1.el9_8
kernel-debug-modules
5.14.0-687.33.1.el9_8
kernel-debug-modules-core
5.14.0-687.33.1.el9_8
kernel-debug-modules-extra
5.14.0-687.33.1.el9_8
kernel-debug-uki-virt
5.14.0-687.33.1.el9_8
kernel-modules
5.14.0-687.33.1.el9_8
kernel-modules-core
5.14.0-687.33.1.el9_8
kernel-modules-extra
5.14.0-687.33.1.el9_8
kernel-tools
5.14.0-687.33.1.el9_8
kernel-tools-libs
5.14.0-687.33.1.el9_8
kernel-uki-virt
5.14.0-687.33.1.el9_8
kernel-uki-virt-addons
5.14.0-687.33.1.el9_8
Связанные CVE
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the ...
In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the...
In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is stil
