Affected: AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 37 more

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: ipvlan: out-of-bounds write caused by unclear skb->cb (CVE-2023-3090) * kernel: cls_flower: out-of-bounds write in fl_set_geneve_opt() (CVE-2023-35788) * kernel: KVM: x86/mmu: race condition in direct_page_fault() (CVE-2022-45869) * kernel: speculative pointer dereference in do_prlimit() in kernel/sys.c (CVE-2023-0458) * kernel: Spectre v2 SMT mitigations problem (CVE-2023-1998)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line.

This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects.

Affected: openEuler:20.03-LTS-SP1: kernel

The Linux Kernel, the operating system core itself. Security Fix(es): A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem.(CVE-2023-1990) The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/power/supply/da9150-charger.c if a physically proximate attacker unplugs a device.(CVE-2023-30772)

The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line.This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects.(CVE-2023-1998)

kernel: KVM: x86/mmu: race condition in direct_page_fault() kernel: speculative pointer dereference in do_prlimit() in kernel/sys.c kernel: Spectre v2 SMT mitigations problem kernel: ipvlan: out-of-bounds write caused by unclear skb->cb kernel: cls_flower: out-of-bounds write in fl_set_geneve_opt()

kernel: KVM: x86/mmu: race condition in direct_page_fault() kernel: speculative pointer dereference in do_prlimit() in kernel/sys.c kernel: Spectre v2 SMT mitigations problem kernel: ipvlan: out-of-bounds write caused by unclear skb->cb kernel: cls_flower: out-of-bounds write in fl_set_geneve_opt()

Security update for the Linux Kernel

Affected: Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-kvm and 114 more

The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line. This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects.

Ein lokaler Angreifer kann eine Schwachstelle im Linux Kernel ausnutzen, um Sicherheitsvorkehrungen zu umgehen.