Описание
ELSA-2025-10854: kernel security update (IMPORTANT)
[6.12.0-55.21.1.0.1_0.OL10]
- nvme-pci: remove two deallocate zeroes quirks [Orabug: 37756650]
- 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]
Обновленные пакеты
Oracle Linux 10
Oracle Linux aarch64
kernel-headers
6.12.0-55.21.1.0.1.el10_0
perf
6.12.0-55.21.1.0.1.el10_0
python3-perf
6.12.0-55.21.1.0.1.el10_0
rtla
6.12.0-55.21.1.0.1.el10_0
rv
6.12.0-55.21.1.0.1.el10_0
kernel-tools
6.12.0-55.21.1.0.1.el10_0
kernel-tools-libs
6.12.0-55.21.1.0.1.el10_0
kernel-cross-headers
6.12.0-55.21.1.0.1.el10_0
kernel-tools-libs-devel
6.12.0-55.21.1.0.1.el10_0
libperf
6.12.0-55.21.1.0.1.el10_0
Oracle Linux x86_64
kernel-abi-stablelists
6.12.0-55.21.1.0.1.el10_0
kernel-core
6.12.0-55.21.1.0.1.el10_0
kernel-debug
6.12.0-55.21.1.0.1.el10_0
kernel-debug-core
6.12.0-55.21.1.0.1.el10_0
kernel-debug-modules
6.12.0-55.21.1.0.1.el10_0
kernel-debug-modules-core
6.12.0-55.21.1.0.1.el10_0
kernel-tools
6.12.0-55.21.1.0.1.el10_0
kernel-tools-libs
6.12.0-55.21.1.0.1.el10_0
kernel-uki-virt
6.12.0-55.21.1.0.1.el10_0
kernel-uki-virt-addons
6.12.0-55.21.1.0.1.el10_0
kernel-debug-devel
6.12.0-55.21.1.0.1.el10_0
kernel-debug-devel-matched
6.12.0-55.21.1.0.1.el10_0
kernel-devel
6.12.0-55.21.1.0.1.el10_0
kernel-devel-matched
6.12.0-55.21.1.0.1.el10_0
kernel-doc
6.12.0-55.21.1.0.1.el10_0
kernel-headers
6.12.0-55.21.1.0.1.el10_0
perf
6.12.0-55.21.1.0.1.el10_0
python3-perf
6.12.0-55.21.1.0.1.el10_0
rtla
6.12.0-55.21.1.0.1.el10_0
rv
6.12.0-55.21.1.0.1.el10_0
kernel
6.12.0-55.21.1.0.1.el10_0
kernel-debug-modules-extra
6.12.0-55.21.1.0.1.el10_0
kernel-debug-uki-virt
6.12.0-55.21.1.0.1.el10_0
kernel-modules
6.12.0-55.21.1.0.1.el10_0
kernel-modules-core
6.12.0-55.21.1.0.1.el10_0
kernel-modules-extra
6.12.0-55.21.1.0.1.el10_0
kernel-cross-headers
6.12.0-55.21.1.0.1.el10_0
kernel-tools-libs-devel
6.12.0-55.21.1.0.1.el10_0
libperf
6.12.0-55.21.1.0.1.el10_0
Связанные CVE
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: exfat: fix random stack corruption after get_block When get_block is called with a buffer_head allocated on the stack, such as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in the following race condition situation. <CPU 0> <CPU 1> mpage_read_folio <<bh on stack>> do_mpage_readpage exfat_get_block bh_read __bh_read get_bh(bh) submit_bh wait_on_buffer ... end_buffer_read_sync __end_buffer_read_notouch unlock_buffer <<keep going>> ... ... ... ... <<bh is not valid out of mpage_read_folio>> . . another_function <<variable A on stack>> put_bh(bh) atomic_dec(bh->b_count) * stack corruption here * This patch returns -EAGAIN if a folio does not have buffers when bh_read needs to be called. By doing this, the caller can fallback to functions like block_read_full_folio(), create a buffer_head in the folio, and then call get_block again. Let's do not call bh_read() with on-stac...
In the Linux kernel, the following vulnerability has been resolved: exfat: fix random stack corruption after get_block When get_block is called with a buffer_head allocated on the stack, such as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in the following race condition situation. <CPU 0> <CPU 1> mpage_read_folio <<bh on stack>> do_mpage_readpage exfat_get_block bh_read __bh_read get_bh(bh) submit_bh wait_on_buffer ... end_buffer_read_sync __end_buffer_read_notouch unlock_buffer <<keep going>> ... ... ... ... <<bh is not valid out of mpage_read_folio>> . . another_function <<variable A on stack>> put_bh(bh) atomic_dec(bh->b_count) * stack corruption here * This patch returns -EAGAIN if a folio does not have buffers when bh_read needs to be called. By doing this, the caller can fallback to functions like block_read_full_folio(), create a buffer_head in the folio, and then call get_block again. Let's do not call bh_read() with on-stack buf...
In the Linux kernel, the following vulnerability has been resolved: exfat: fix random stack corruption after get_block When get_block is called with a buffer_head allocated on the stack, such as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in the following race condition situation. <CPU 0> <CPU 1> mpage_read_folio <<bh on stack>> do_mpage_readpage exfat_get_block bh_read __bh_read get_bh(bh) submit_bh wait_on_buffer ... end_buffer_read_sync __end_buffer_read_notouch unlock_buffer <<keep going>> ... ... ... ... <<bh is not valid out of mpage_read_folio>> . . another_function <<variable A on stack>> put_bh(bh) atomic_dec(bh->b_count) * stack corruption here
In the Linux kernel, the following vulnerability has been resolved: e ...
In the Linux kernel, the following vulnerability has been resolved: exfat: fix random stack corruption after get_block When get_block is called with a buffer_head allocated on the stack, such as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in the following race condition situation. <CPU 0> <CPU 1> mpage_read_folio <<bh on stack>> do_mpage_readpage exfat_get_block bh_read __bh_read get_bh(bh) submit_bh wait_on_buffer ... end_buffer_read_sync __end_buffer_read_notouch unlock_buffer <<keep going>> ... ... ... ... <<bh is not valid out of mpage_read_folio>> . . another_function <<variable A on stack>> put_bh(bh) atomic_dec(bh->b_count) * stack corruption h...