{"id":"OESA-2026-3205","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nArm 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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ac97: fix a double free in snd_ac97_controller_register()\n\nIf ac97_add_adapter() fails, put_device() is the correct way to drop\nthe device reference. kfree() is not required.\nAdd kfree() if idr_alloc() fails and in ac97_adapter_release() to do\nthe cleanup.\n\nFound by code review.(CVE-2025-71192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak\n\nFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:\ngs_usb_receive_bulk_callback(): fix URB memory leak").\n\nIn ems_usb_open(), the URBs for USB-in transfers are allocated, added to\nthe dev->rx_submitted anchor and submitted. In the complete callback\nems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In\nems_usb_close() the URBs are freed by calling\nusb_kill_anchored_urbs(&dev->rx_submitted).\n\nHowever, this does not take into account that the USB framework unanchors\nthe URB before the complete function is called. This means that once an\nin-URB has been completed, it is no longer anchored and is ultimately not\nreleased in ems_usb_close().\n\nFix the memory leak by anchoring the URB in the\nems_usb_read_bulk_callback() to the dev->rx_submitted anchor.(CVE-2026-23058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlocking/rtmutex: Skip remove_waiter() when waiter is not enqueued\n\nsyzbot triggered the following splat in remove_waiter() via\nFUTEX_CMP_REQUEUE_PI:\n\n  KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f]\n   class_raw_spinlock_constructor\n   remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561\n   rt_mutex_start_proxy_lock+0x103/0x120\n   futex_requeue+0x10e4/0x20d0\n   __x64_sys_futex+0x34f/0x4d0\n\ntask_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection,\nleaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead\nof current in remove_waiter()") made this fatal.\n\nFurthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter()\nupon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock\nreturn correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock()\n(where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to\naccount for try_to_take_rt_mutex().(CVE-2026-53163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: omninet: fix memory corruption with small endpoint\n\nMake sure that the bulk-out buffers are at least as large as the\nhardcoded transfer size to avoid user-controlled slab corruption should\na malicious device report a smaller endpoint max packet size than\nexpected.(CVE-2026-63928)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsecurity/keys: fix missed RCU read section on lookup\n\nNicholas Carlini reports that the keyring code calls assoc_array_find()\nin find_key_to_update() without holding the RCU read lock, while the\nassoc_array_gc() code really is designed around removing the node from\nthe tree and then freeing it after an RCU grace-period.\n\nThe regular key handling doesn't see this because holding the keyring\nsemaphore hides any lifetime issues, but the persistent key handling\nuses a different model.\n\nInstead of extending the keyring locking, just do the simple RCU locking\nthat the assoc_array was designed for.(CVE-2026-64015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: resample the data fork mapping after cycling ILOCK\n\nxfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode,\na data fork mapping, and a cow fork mapping.  Unfortunately, these two\nhelpers cycle the ILOCK to grab a transaction, which means that the\nmappings are stale as soon as we reacquire the ILOCK.  Currently we\nrefresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but\nwe don't refresh the data fork mapping beforehand, which means that the\nxfs_bmap_trim_cow in that function queries the refcount btree about the\nwrong physical blocks and returns an inaccurate value in *shared.\n\nIf *shared is now false, the directio write proceeds with a stale data\nfork mapping.  Fix this by querying the data fork mapping if the\nsequence counter changes across the ILOCK cycle.(CVE-2026-64600)","modified":"2026-08-18T01:21:25.982682662Z","published":"2026-08-01T11:12:04Z","upstream":["CVE-2025-10263","CVE-2025-71192","CVE-2026-23058","CVE-2026-53163","CVE-2026-63928","CVE-2026-64015","CVE-2026-64600"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-10263"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71192"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53163"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63928"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64600"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:20.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2607.4.0.0382.oe2003sp4"}]}],"ecosystem_specific":{"src":["kernel-4.19.90-2607.4.0.0382.oe2003sp4.src.rpm"],"x86_64":["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"],"aarch64":["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"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3205.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"}]}