Описание
ELSA-2025-15471: kernel security update (IMPORTANT)
[4.18.0-553.74.1_10.OL8]
- 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.74.1_10]
- posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() (Oleg Nesterov) [RHEL-112775] {CVE-2025-38352}
[4.18.0-553.73.1_10]
- ACPI: resource: Honor MADT INT_SRC_OVR settings for IRQ1 on AMD Zen (Jay Shin) [RHEL-108360]
- ACPI: resource: Always use MADT override IRQ settings for all legacy non i8042 IRQs (Jay Shin) [RHEL-108360]
- s390/pci: Allow automatic recovery with minimal driver support (Mete Durlu) [RHEL-110234]
- bpf: Don't use tnum_range on array range checking for poke descriptors (CKI Backport Bot) [RHEL-109298] {CVE-2022-49985}
- s390/ism: fix concurrency management in ism_cmd() (Mete Durlu) [RHEL-110208]
Обновленные пакеты
Oracle Linux 8
Oracle Linux aarch64
kernel-tools-libs-devel
4.18.0-553.74.1.el8_10
bpftool
4.18.0-553.74.1.el8_10
kernel-cross-headers
4.18.0-553.74.1.el8_10
kernel-headers
4.18.0-553.74.1.el8_10
kernel-tools
4.18.0-553.74.1.el8_10
kernel-tools-libs
4.18.0-553.74.1.el8_10
perf
4.18.0-553.74.1.el8_10
python3-perf
4.18.0-553.74.1.el8_10
Oracle Linux x86_64
kernel-tools-libs-devel
4.18.0-553.74.1.el8_10
bpftool
4.18.0-553.74.1.el8_10
kernel
4.18.0-553.74.1.el8_10
kernel-abi-stablelists
4.18.0-553.74.1.el8_10
kernel-core
4.18.0-553.74.1.el8_10
kernel-cross-headers
4.18.0-553.74.1.el8_10
kernel-debug
4.18.0-553.74.1.el8_10
kernel-debug-core
4.18.0-553.74.1.el8_10
kernel-debug-devel
4.18.0-553.74.1.el8_10
kernel-debug-modules
4.18.0-553.74.1.el8_10
kernel-debug-modules-extra
4.18.0-553.74.1.el8_10
kernel-devel
4.18.0-553.74.1.el8_10
kernel-doc
4.18.0-553.74.1.el8_10
kernel-headers
4.18.0-553.74.1.el8_10
kernel-modules
4.18.0-553.74.1.el8_10
kernel-modules-extra
4.18.0-553.74.1.el8_10
kernel-tools
4.18.0-553.74.1.el8_10
kernel-tools-libs
4.18.0-553.74.1.el8_10
perf
4.18.0-553.74.1.el8_10
python3-perf
4.18.0-553.74.1.el8_10
Связанные CVE
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: bpf: Don't use tnum_range on array range checking for poke descriptors Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which is based on a customized syzkaller: BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0 Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x22...
In the Linux kernel, the following vulnerability has been resolved: bpf: Don't use tnum_range on array range checking for poke descriptors Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which is based on a customized syzkaller: BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0 Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x22...
In the Linux kernel, the following vulnerability has been resolved: bpf: Don't use tnum_range on array range checking for poke descriptors Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which is based on a customized syzkaller: BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0 Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_l
In the Linux kernel, the following vulnerability has been resolved: b ...
In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail. Add the tsk->exit_state check into run_posix_cpu_timers() to fix this. This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case.