Описание
ELSA-2026-49870: kernel security, bug fix, and enhancement update (LOW)
[5.14.0-687.34.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.34.1]
- s390/mm: Ensure physical addr derived from page is passed in to uv_convert_from_secure() (Lucas Oakley) [RHEL-192430]
- s390/mm: Fix phys_to_folio() usage in do_secure_storage_access() (Charles Haithcock) [RHEL-216471]
- gfs2: page poisoning fix (CKI Backport Bot) [RHEL-214021]
- timers: Fix NULL function pointer race in timer_shutdown_sync() (CKI Backport Bot) [RHEL-189940] {CVE-2025-68214}
- net: wwan: t7xx: Add delay between MD and SAP suspend (CKI Backport Bot) [RHEL-184273]
Обновленные пакеты
Oracle Linux 9
Oracle Linux aarch64
kernel-cross-headers
5.14.0-687.34.1.el9_8
kernel-headers
5.14.0-687.34.1.el9_8
kernel-tools
5.14.0-687.34.1.el9_8
kernel-tools-libs
5.14.0-687.34.1.el9_8
kernel-tools-libs-devel
5.14.0-687.34.1.el9_8
libperf
5.14.0-687.34.1.el9_8
perf
5.14.0-687.34.1.el9_8
python3-perf
5.14.0-687.34.1.el9_8
rtla
5.14.0-687.34.1.el9_8
rv
5.14.0-687.34.1.el9_8
Oracle Linux x86_64
kernel
5.14.0-687.34.1.el9_8
kernel-abi-stablelists
5.14.0-687.34.1.el9_8
kernel-core
5.14.0-687.34.1.el9_8
kernel-cross-headers
5.14.0-687.34.1.el9_8
kernel-debug
5.14.0-687.34.1.el9_8
kernel-debug-core
5.14.0-687.34.1.el9_8
kernel-debug-devel
5.14.0-687.34.1.el9_8
kernel-debug-devel-matched
5.14.0-687.34.1.el9_8
kernel-debug-modules
5.14.0-687.34.1.el9_8
kernel-debug-modules-core
5.14.0-687.34.1.el9_8
kernel-debug-modules-extra
5.14.0-687.34.1.el9_8
kernel-debug-uki-virt
5.14.0-687.34.1.el9_8
kernel-devel
5.14.0-687.34.1.el9_8
kernel-devel-matched
5.14.0-687.34.1.el9_8
kernel-doc
5.14.0-687.34.1.el9_8
kernel-headers
5.14.0-687.34.1.el9_8
kernel-modules
5.14.0-687.34.1.el9_8
kernel-modules-core
5.14.0-687.34.1.el9_8
kernel-modules-extra
5.14.0-687.34.1.el9_8
kernel-tools
5.14.0-687.34.1.el9_8
kernel-tools-libs
5.14.0-687.34.1.el9_8
kernel-tools-libs-devel
5.14.0-687.34.1.el9_8
kernel-uki-virt
5.14.0-687.34.1.el9_8
kernel-uki-virt-addons
5.14.0-687.34.1.el9_8
libperf
5.14.0-687.34.1.el9_8
perf
5.14.0-687.34.1.el9_8
python3-perf
5.14.0-687.34.1.el9_8
rtla
5.14.0-687.34.1.el9_8
rv
5.14.0-687.34.1.el9_8
Связанные CVE
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIR...
In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> ex...
In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer
timers: Fix NULL function pointer race in timer_shutdown_sync()
In the Linux kernel, the following vulnerability has been resolved: t ...