An update for kernel is now available for openEuler-22.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-1861 Final 1.0 1.0 2026-04-11 Initial 2026-04-11 2026-04-11 openEuler SA Tool V1.0 2026-04-11 kernel security update An update for kernel is now available for openEuler-22.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: apparmor: fix unprivileged local user can do privileged policy management An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface. This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation. The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces. Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check.(CVE-2026-23268) In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: validate USB endpoints The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.(CVE-2026-23290) In the Linux kernel, the following vulnerability has been resolved: ksmbd: Compare MACs in constant time To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().(CVE-2026-23364) In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: <TASK> mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f </TASK> ---[ end trace 0000000000000000 ]---(CVE-2026-23401) An update for kernel is now available for openEuler-20.03-LTS-SP4/openEuler-22.03-LTS-SP4/openEuler-22.03-LTS-SP3. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1861 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23268 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23290 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23364 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23401 https://nvd.nist.gov/vuln/detail/CVE-2026-23268 https://nvd.nist.gov/vuln/detail/CVE-2026-23290 https://nvd.nist.gov/vuln/detail/CVE-2026-23364 https://nvd.nist.gov/vuln/detail/CVE-2026-23401 openEuler-22.03-LTS-SP4 bpftool-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm bpftool-debuginfo-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-debuginfo-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-debugsource-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-devel-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-headers-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-source-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-tools-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-tools-debuginfo-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm kernel-tools-devel-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm perf-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm perf-debuginfo-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm python3-perf-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm python3-perf-debuginfo-5.10.0-308.0.0.211.oe2203sp4.aarch64.rpm bpftool-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm bpftool-debuginfo-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-debuginfo-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-debugsource-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-devel-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-headers-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-source-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-tools-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-tools-debuginfo-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-tools-devel-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm perf-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm perf-debuginfo-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm python3-perf-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm python3-perf-debuginfo-5.10.0-308.0.0.211.oe2203sp4.x86_64.rpm kernel-5.10.0-308.0.0.211.oe2203sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved: apparmor: fix unprivileged local user can do privileged policy management An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface. This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation. The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces. Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check. 2026-04-11 CVE-2026-23268 openEuler-22.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-04-11 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1861 In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: validate USB endpoints The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints. 2026-04-11 CVE-2026-23290 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-04-11 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1861 In the Linux kernel, the following vulnerability has been resolved: ksmbd: Compare MACs in constant time To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq(). 2026-04-11 CVE-2026-23364 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-04-11 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1861 In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: <TASK> mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f </TASK> ---[ end trace 0000000000000000 ]--- 2026-04-11 CVE-2026-23401 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-04-11 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1861