Описание
ELSA-2026-0786: kernel security update (IMPORTANT)
[6.12.0-124.28.1]
- Add new Oracle Linux Driver Signing (key 1) certificate [Orabug: 37985782]
- 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
- Update module name for cryptographic module [Orabug: 37400433]
- Clean git history at setup stage
[6.12.0-124.28.1]
- libceph: fix potential use-after-free in have_mon_and_osd_map() (CKI Backport Bot) [RHEL-137403] {CVE-2025-68285}
Обновленные пакеты
Oracle Linux 10
Oracle Linux aarch64
kernel-headers
6.12.0-124.28.1.el10_1
perf
6.12.0-124.28.1.el10_1
python3-perf
6.12.0-124.28.1.el10_1
rtla
6.12.0-124.28.1.el10_1
rv
6.12.0-124.28.1.el10_1
kernel-tools
6.12.0-124.28.1.el10_1
kernel-tools-libs
6.12.0-124.28.1.el10_1
kernel-cross-headers
6.12.0-124.28.1.el10_1
kernel-tools-libs-devel
6.12.0-124.28.1.el10_1
libperf
6.12.0-124.28.1.el10_1
Oracle Linux x86_64
kernel
6.12.0-124.28.1.el10_1
kernel-debug-modules
6.12.0-124.28.1.el10_1
kernel-debug-modules-core
6.12.0-124.28.1.el10_1
kernel-debug-uki-virt
6.12.0-124.28.1.el10_1
kernel-modules
6.12.0-124.28.1.el10_1
kernel-modules-extra
6.12.0-124.28.1.el10_1
kernel-modules-extra-matched
6.12.0-124.28.1.el10_1
kernel-tools-libs
6.12.0-124.28.1.el10_1
kernel-debug-devel
6.12.0-124.28.1.el10_1
kernel-debug-devel-matched
6.12.0-124.28.1.el10_1
kernel-devel
6.12.0-124.28.1.el10_1
kernel-devel-matched
6.12.0-124.28.1.el10_1
kernel-doc
6.12.0-124.28.1.el10_1
kernel-headers
6.12.0-124.28.1.el10_1
perf
6.12.0-124.28.1.el10_1
python3-perf
6.12.0-124.28.1.el10_1
rtla
6.12.0-124.28.1.el10_1
rv
6.12.0-124.28.1.el10_1
kernel-abi-stablelists
6.12.0-124.28.1.el10_1
kernel-core
6.12.0-124.28.1.el10_1
kernel-debug
6.12.0-124.28.1.el10_1
kernel-debug-core
6.12.0-124.28.1.el10_1
kernel-debug-modules-extra
6.12.0-124.28.1.el10_1
kernel-modules-core
6.12.0-124.28.1.el10_1
kernel-tools
6.12.0-124.28.1.el10_1
kernel-uki-virt
6.12.0-124.28.1.el10_1
kernel-uki-virt-addons
6.12.0-124.28.1.el10_1
kernel-cross-headers
6.12.0-124.28.1.el10_1
kernel-tools-libs-devel
6.12.0-124.28.1.el10_1
libperf
6.12.0-124.28.1.el10_1
Связанные CVE
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4...
In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon
libceph: fix potential use-after-free in have_mon_and_osd_map()
In the Linux kernel, the following vulnerability has been resolved: l ...
In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_...