Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

oracle-oval логотип

ELSA-2025-23279

Опубликовано: 17 дек. 2025
Источник: oracle-oval
Платформа: Oracle Linux 10

Описание

ELSA-2025-23279: kernel security update (IMPORTANT)

[6.12.0-124.21.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.21.1]

  • CVE-2025-38499 kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns (Abhi Das) [RHEL-129282] {CVE-2025-38499}
  • net: tun: Update napi->skb after XDP process (CKI Backport Bot) [RHEL-122247] {CVE-2025-39984}

Обновленные пакеты

Oracle Linux 10

Oracle Linux aarch64

kernel-headers

6.12.0-124.21.1.el10_1

perf

6.12.0-124.21.1.el10_1

python3-perf

6.12.0-124.21.1.el10_1

rtla

6.12.0-124.21.1.el10_1

rv

6.12.0-124.21.1.el10_1

kernel-tools

6.12.0-124.21.1.el10_1

kernel-tools-libs

6.12.0-124.21.1.el10_1

kernel-cross-headers

6.12.0-124.21.1.el10_1

kernel-tools-libs-devel

6.12.0-124.21.1.el10_1

libperf

6.12.0-124.21.1.el10_1

Oracle Linux x86_64

kernel-debug

6.12.0-124.21.1.el10_1

kernel-debug-modules-extra

6.12.0-124.21.1.el10_1

kernel-debug-uki-virt

6.12.0-124.21.1.el10_1

kernel-modules

6.12.0-124.21.1.el10_1

kernel-modules-core

6.12.0-124.21.1.el10_1

kernel-tools

6.12.0-124.21.1.el10_1

kernel-uki-virt-addons

6.12.0-124.21.1.el10_1

kernel-debug-devel

6.12.0-124.21.1.el10_1

kernel-debug-devel-matched

6.12.0-124.21.1.el10_1

kernel-devel

6.12.0-124.21.1.el10_1

kernel-devel-matched

6.12.0-124.21.1.el10_1

kernel-doc

6.12.0-124.21.1.el10_1

kernel-headers

6.12.0-124.21.1.el10_1

perf

6.12.0-124.21.1.el10_1

python3-perf

6.12.0-124.21.1.el10_1

rtla

6.12.0-124.21.1.el10_1

rv

6.12.0-124.21.1.el10_1

kernel

6.12.0-124.21.1.el10_1

kernel-abi-stablelists

6.12.0-124.21.1.el10_1

kernel-core

6.12.0-124.21.1.el10_1

kernel-debug-core

6.12.0-124.21.1.el10_1

kernel-debug-modules

6.12.0-124.21.1.el10_1

kernel-debug-modules-core

6.12.0-124.21.1.el10_1

kernel-modules-extra

6.12.0-124.21.1.el10_1

kernel-modules-extra-matched

6.12.0-124.21.1.el10_1

kernel-tools-libs

6.12.0-124.21.1.el10_1

kernel-uki-virt

6.12.0-124.21.1.el10_1

kernel-cross-headers

6.12.0-124.21.1.el10_1

kernel-tools-libs-devel

6.12.0-124.21.1.el10_1

libperf

6.12.0-124.21.1.el10_1

Связанные CVE

Связанные уязвимости

ubuntu
2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: net: tun: Update napi->skb after XDP process The syzbot report a UAF issue: BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline] BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline] BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079 CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 skb_reset_mac_header include/linux/skbuff.h:3150 [inline] napi_frags_skb net/core/gro.c:723 [inline] napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920 tun_chr_write_iter+0x113/0x200 drivers/net/tun....

nvd
2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: net: tun: Update napi->skb after XDP process The syzbot report a UAF issue: BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline] BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline] BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079 CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 skb_reset_mac_header include/linux/skbuff.h:3150 [inline] napi_frags_skb net/core/gro.c:723 [inline] napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920 tun_c

debian
2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: n ...

ubuntu
4 месяца назад

In the Linux kernel, the following vulnerability has been resolved: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above.

CVSS3: 7
redhat
4 месяца назад

In the Linux kernel, the following vulnerability has been resolved: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above.