Описание
ELSA-2026-49857: kernel security, bug fix, and enhancement update (MODERATE)
[4.18.0-553.151.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.151.1]
- net: dns_resolver: allow shorter names in dns_query() (Paulo Alcantara) [RHEL-213976]
- net/dns_resolver: use kasprintf + kmemdup_nul to simplify dns_query (Paulo Alcantara) [RHEL-213976]
- net/dns_resolver: consolidate namelen checks in dns_query (Paulo Alcantara) [RHEL-213976]
- dns: remove redundant zero length namelen check (Paulo Alcantara) [RHEL-213976]
- ipc: limit next_id allocation to the valid ID range (Rafael Aquini) [RHEL-188216] {CVE-2026-52923}
- KVM: s390: Limit adapter indicator access to mapped page (Christoph Schlameuss) [RHEL-183880]
Обновленные пакеты
Oracle Linux 8
Oracle Linux aarch64
kernel-tools-libs-devel
4.18.0-553.151.1.el8_10
bpftool
4.18.0-553.151.1.el8_10
kernel-cross-headers
4.18.0-553.151.1.el8_10
kernel-headers
4.18.0-553.151.1.el8_10
kernel-tools
4.18.0-553.151.1.el8_10
kernel-tools-libs
4.18.0-553.151.1.el8_10
perf
4.18.0-553.151.1.el8_10
python3-perf
4.18.0-553.151.1.el8_10
Oracle Linux x86_64
kernel-tools-libs-devel
4.18.0-553.151.1.el8_10
bpftool
4.18.0-553.151.1.el8_10
kernel
4.18.0-553.151.1.el8_10
kernel-abi-stablelists
4.18.0-553.151.1.el8_10
kernel-core
4.18.0-553.151.1.el8_10
kernel-cross-headers
4.18.0-553.151.1.el8_10
kernel-debug
4.18.0-553.151.1.el8_10
kernel-debug-core
4.18.0-553.151.1.el8_10
kernel-debug-devel
4.18.0-553.151.1.el8_10
kernel-debug-modules
4.18.0-553.151.1.el8_10
kernel-debug-modules-extra
4.18.0-553.151.1.el8_10
kernel-devel
4.18.0-553.151.1.el8_10
kernel-doc
4.18.0-553.151.1.el8_10
kernel-headers
4.18.0-553.151.1.el8_10
kernel-modules
4.18.0-553.151.1.el8_10
kernel-modules-extra
4.18.0-553.151.1.el8_10
kernel-tools
4.18.0-553.151.1.el8_10
kernel-tools-libs
4.18.0-553.151.1.el8_10
perf
4.18.0-553.151.1.el8_10
python3-perf
4.18.0-553.151.1.el8_10
Связанные 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
In the Linux kernel, the following vulnerability has been resolved: i ...