An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-3205 Final 1.0 1.0 2026-08-01 Initial 2026-08-01 2026-08-01 openEuler SA Tool V1.0 2026-08-01 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263) In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix a double free in snd_ac97_controller_register() If ac97_add_adapter() fails, put_device() is the correct way to drop the device reference. kfree() is not required. Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do the cleanup. Found by code review.(CVE-2025-71192) In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.(CVE-2026-23058) In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().(CVE-2026-53163) In the Linux kernel, the following vulnerability has been resolved: USB: serial: omninet: fix memory corruption with small endpoint Make sure that the bulk-out buffers are at least as large as the hardcoded transfer size to avoid user-controlled slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63928) In the Linux kernel, the following vulnerability has been resolved: security/keys: fix missed RCU read section on lookup Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period. The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model. Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for.(CVE-2026-64015) In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.(CVE-2026-64600) An update for kernel is now available for openEuler-20.03-LTS-SP4/openEuler-22.03-LTS-SP3/openEuler-24.03-LTS/openEuler-24.03-LTS-SP2. openEuler Security has rated this update as having a security impact of critical. 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. Critical kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-10263 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71192 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23058 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53163 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-63928 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-64015 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-64600 https://nvd.nist.gov/vuln/detail/CVE-2025-10263 https://nvd.nist.gov/vuln/detail/CVE-2025-71192 https://nvd.nist.gov/vuln/detail/CVE-2026-23058 https://nvd.nist.gov/vuln/detail/CVE-2026-53163 https://nvd.nist.gov/vuln/detail/CVE-2026-63928 https://nvd.nist.gov/vuln/detail/CVE-2026-64015 https://nvd.nist.gov/vuln/detail/CVE-2026-64600 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm perf-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm kernel-4.19.90-2607.4.0.0382.oe2003sp4.src.rpm bpftool-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm kernel-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm perf-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level. 2026-08-01 CVE-2025-10263 openEuler-20.03-LTS-SP4 Critical 9.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N kernel security update 2026-08-01 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205 In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix a double free in snd_ac97_controller_register() If ac97_add_adapter() fails, put_device() is the correct way to drop the device reference. kfree() is not required. Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do the cleanup. Found by code review. 2026-08-01 CVE-2025-71192 openEuler-20.03-LTS-SP4 Medium 5.3 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H kernel security update 2026-08-01 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205 In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor. 2026-08-01 CVE-2026-23058 openEuler-20.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-08-01 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205 In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex(). 2026-08-01 CVE-2026-53163 openEuler-20.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-08-01 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205 In the Linux kernel, the following vulnerability has been resolved: USB: serial: omninet: fix memory corruption with small endpoint Make sure that the bulk-out buffers are at least as large as the hardcoded transfer size to avoid user-controlled slab corruption should a malicious device report a smaller endpoint max packet size than expected. 2026-08-01 CVE-2026-63928 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-08-01 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205 In the Linux kernel, the following vulnerability has been resolved: security/keys: fix missed RCU read section on lookup Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period. The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model. Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for. 2026-08-01 CVE-2026-64015 openEuler-20.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-08-01 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205 In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle. 2026-08-01 CVE-2026-64600 openEuler-20.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-08-01 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205