{"schema_version":"1.7.2","id":"OESA-2026-2416","modified":"2026-05-22T13:19:33Z","published":"2026-05-22T13:19:33Z","upstream":["CVE-2025-38488","CVE-2025-39841","CVE-2025-40261","CVE-2025-40324","CVE-2025-68185","CVE-2025-68214","CVE-2025-68288","CVE-2025-68820","CVE-2025-71064","CVE-2026-23273","CVE-2026-31393","CVE-2026-31447","CVE-2026-31477","CVE-2026-31527","CVE-2026-31611","CVE-2026-31612","CVE-2026-31704","CVE-2026-31708","CVE-2026-31754","CVE-2026-31755","CVE-2026-31771","CVE-2026-43047","CVE-2026-43048","CVE-2026-43171","CVE-2026-43212","CVE-2026-43261","CVE-2026-43428","CVE-2026-43488","CVE-2026-46333"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in crypt_message when using async crypto\n\nThe CVE-2024-50047 fix removed asynchronous crypto handling from\ncrypt_message(), assuming all crypto operations are synchronous.\nHowever, when hardware crypto accelerators are used, this can cause\nuse-after-free crashes:\n\n  crypt_message()\n    // Allocate the creq buffer containing the req\n    creq = smb2_get_aead_req(..., &req);\n\n    // Async encryption returns -EINPROGRESS immediately\n    rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);\n\n    // Free creq while async operation is still in progress\n    kvfree_sensitive(creq, ...);\n\nHardware crypto modules often implement async AEAD operations for\nperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,\nthe operation completes asynchronously. Without crypto_wait_req(),\nthe function immediately frees the request buffer, leading to crashes\nwhen the driver later accesses the freed memory.\n\nThis results in a use-after-free condition when the hardware crypto\ndriver later accesses the freed request structure, leading to kernel\ncrashes with NULL pointer dereferences.\n\nThe issue occurs because crypto_alloc_aead() with mask=0 doesn't\nguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in\nthe mask, async implementations can be selected.\n\nFix by restoring the async crypto handling:\n- DECLARE_CRYPTO_WAIT(wait) for completion tracking\n- aead_request_set_callback() for async completion notification\n- crypto_wait_req() to wait for operation completion\n\nThis ensures the request buffer isn't freed until the crypto operation\ncompletes, whether synchronous or asynchronous, while preserving the\nCVE-2024-50047 fix.(CVE-2025-38488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix buffer free/clear order in deferred receive path\n\nFix a use-after-free window by correcting the buffer release sequence in\nthe deferred receive path. The code freed the RQ buffer first and only\nthen cleared the context pointer under the lock. Concurrent paths (e.g.,\nABTS and the repost path) also inspect and release the same pointer under\nthe lock, so the old order could lead to double-free/UAF.\n\nNote that the repost path already uses the correct pattern: detach the\npointer under the lock, then free it after dropping the lock. The\ndeferred path should do the same.(CVE-2025-39841)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()\n\nnvme_fc_delete_assocation() waits for pending I/O to complete before\nreturning, and an error can cause ->ioerr_work to be queued after\ncancel_work_sync() had been called.  Move the call to cancel_work_sync() to\nbe after nvme_fc_delete_association() to ensure ->ioerr_work is not running\nwhen the nvme_fc_ctrl object is freed.  Otherwise the following can occur:\n\n[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL\n[ 1135.917705] ------------[ cut here ]------------\n[ 1135.922336] kernel BUG at lib/list_debug.c:52!\n[ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)\n[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025\n[ 1135.950969] Workqueue:  0x0 (nvme-wq)\n[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b\n[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046\n[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000\n[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0\n[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08\n[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100\n[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0\n[ 1136.020677] FS:  0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000\n[ 1136.028765] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0\n[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[ 1136.055910] PKRU: 55555554\n[ 1136.058623] Call Trace:\n[ 1136.061074]  <TASK>\n[ 1136.063179]  ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.067540]  ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.071898]  ? move_linked_works+0x4a/0xa0\n[ 1136.075998]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.081744]  ? __die_body.cold+0x8/0x12\n[ 1136.085584]  ? die+0x2e/0x50\n[ 1136.088469]  ? do_trap+0xca/0x110\n[ 1136.091789]  ? do_error_trap+0x65/0x80\n[ 1136.095543]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.101289]  ? exc_invalid_op+0x50/0x70\n[ 1136.105127]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.110874]  ? asm_exc_invalid_op+0x1a/0x20\n[ 1136.115059]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.120806]  move_linked_works+0x4a/0xa0\n[ 1136.124733]  worker_thread+0x216/0x3a0\n[ 1136.128485]  ? __pfx_worker_thread+0x10/0x10\n[ 1136.132758]  kthread+0xfa/0x240\n[ 1136.135904]  ? __pfx_kthread+0x10/0x10\n[ 1136.139657]  ret_from_fork+0x31/0x50\n[ 1136.143236]  ? __pfx_kthread+0x10/0x10\n[ 1136.146988]  ret_from_fork_asm+0x1a/0x30\n[ 1136.150915]  </TASK>(CVE-2025-40261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Fix crash in nfsd4_read_release()\n\nWhen tracing is enabled, the trace_nfsd_read_done trace point\ncrashes during the pynfs read.testNoFh test.(CVE-2025-40324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing\n\nTheoretically it's an oopsable race, but I don't believe one can manage\nto hit it on real hardware; might become doable on a KVM, but it still\nwon't be easy to attack.\n\nAnyway, it's easy to deal with - since xdr_encode_hyper() is just a call of\nput_unaligned_be64(), we can put that under ->d_lock and be done with that.(CVE-2025-68185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntimers: Fix NULL function pointer race in timer_shutdown_sync()\n\nThere is a race condition between timer_shutdown_sync() and timer\nexpiration that can lead to hitting a WARN_ON in expire_timers().\n\nThe issue occurs when timer_shutdown_sync() clears the timer function\nto NULL while the timer is still running on another CPU. The race\nscenario looks like this:\n\nCPU0\t\t\t\t\tCPU1\n\t\t\t\t\t<SOFTIRQ>\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tbase->running_timer = timer;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t[call_timer_fn enter]\n\t\t\t\t\tmod_timer()\n\t\t\t\t\t...\ntimer_shutdown_sync()\nlock_timer_base()\n// For now, will not detach the timer but only clear its function to NULL\nif (base->running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer->function = NULL;\nunlock_timer_base()\n\t\t\t\t\t[call_timer_fn exit]\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\tbase->running_timer = NULL;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t...\n\t\t\t\t\t// Now timer is pending while its function set to NULL.\n\t\t\t\t\t// next timer trigger\n\t\t\t\t\t<SOFTIRQ>\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tWARN_ON_ONCE(!fn) // hit\n\t\t\t\t\t...\nlock_timer_base()\n// Now timer will detach\nif (base->running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer->function = NULL;\nunlock_timer_base()\n\nThe problem is that timer_shutdown_sync() clears the timer function\nregardless of whether the timer is currently running. This can leave a\npending timer with a NULL function pointer, which triggers the\nWARN_ON_ONCE(!fn) check in expire_timers().\n\nFix this by only clearing the timer function when actually detaching the\ntimer. If the timer is running, leave the function pointer intact, which is\nsafe because the timer will be properly detached when it finishes running.(CVE-2025-68214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: Fix memory leak in USB bulk transport\n\nA kernel memory leak was identified by the 'ioctl_sg01' test from Linux\nTest Project (LTP). The following bytes were mainly observed: 0x53425355.\n\nWhen USB storage devices incorrectly skip the data phase with status data,\nthe code extracts/validates the CSW from the sg buffer, but fails to clear\nit afterwards. This leaves status protocol data in srb's transfer buffer,\nsuch as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can\nlead to USB protocols leaks to user space through SCSI generic (/dev/sg*)\ninterfaces, such as the one seen here when the LTP test requested 512 KiB.\n\nFix the leak by zeroing the CSW data in srb's transfer buffer immediately\nafter the validation of devices that skip data phase.\n\nNote: Differently from CVE-2018-1000204, which fixed a big leak by zero-\ning pages at allocation time, this leak occurs after allocation, when USB\nprotocol data is written to already-allocated sg pages.(CVE-2025-68288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: xattr: fix null pointer deref in ext4_raw_inode()\n\nIf ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),\niloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()\nlacks error checking, this will lead to a null pointer dereference\nin ext4_raw_inode(), called right after ext4_get_inode_loc().\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: using the num_tqps in the vf driver to apply for resources\n\nCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqp\nis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set to\nmin(new_tqps, hdev->num_tqps);  Therefore, kinfo->num_tqps may be smaller\nthan hdev->num_tqps, which causes some hdev->htqp[i] to remain\nuninitialized in hclgevf_knic_setup().\n\nThus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,\nensuring that the lengths of hdev->htqp and kinfo->tqp are consistent\nand that all elements are properly initialized.(CVE-2025-71064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: observe an RCU grace period in macvlan_common_newlink() error path\n\nvalis reported that a race condition still happens after my prior patch.\n\nmacvlan_common_newlink() might have made @dev visible before\ndetecting an error, and its caller will directly call free_netdev(dev).\n\nWe must respect an RCU period, either in macvlan or the core networking\nstack.\n\nAfter adding a temporary mdelay(1000) in macvlan_forward_source_one()\nto open the race window, valis repro was:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\nip link add mv0 link p2 type macvlan mode source\n\n(ip link add invalid% link p2 type macvlan mode source macaddr add\n00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4\nPING 1.2.3.4 (1.2.3.4): 56 data bytes\nRTNETLINK answers: Invalid argument\n\nBUG: KASAN: slab-use-after-free in macvlan_forward_source\n(drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nRead of size 8 at addr ffff888016bb89c0 by task e/175\n\nCPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n<IRQ>\ndump_stack_lvl (lib/dump_stack.c:123)\nprint_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nkasan_report (mm/kasan/report.c:597)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nmacvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\n? tasklet_init (kernel/softirq.c:983)\nmacvlan_handle_frame (drivers/net/macvlan.c:501)\n\nAllocated by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\n__kasan_kmalloc (mm/kasan/common.c:419)\n__kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657\nmm/slub.c:7140)\nalloc_netdev_mqs (net/core/dev.c:12012)\nrtnl_create_link (net/core/rtnetlink.c:3648)\nrtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)\n\nFreed by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\nkasan_save_free_info (mm/kasan/generic.c:587)\n__kasan_slab_free (mm/kasan/common.c:287)\nkfree (mm/slub.c:6674 mm/slub.c:6882)\nrtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)(CVE-2026-23273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp->data without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads\n   4 bytes past the header (needs cmd_len >= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header\n   (needs cmd_len >= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check.  If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.(CVE-2026-31393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: reject mount if bigalloc with s_first_data_block != 0\n\nbigalloc with s_first_data_block != 0 is not supported, reject mounting\nit.(CVE-2026-31447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix memory leaks and NULL deref in smb2_lock()\n\nsmb2_lock() has three error handling issues after list_del() detaches\nsmb_lock from lock_list at no_check_cl:\n\n1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK\n   path, goto out leaks smb_lock and its flock because the out:\n   handler only iterates lock_list and rollback_list, neither of\n   which contains the detached smb_lock.\n\n2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out\n   leaks smb_lock and flock for the same reason.  The error code\n   returned to the dispatcher is also stale.\n\n3) In the rollback path, smb_flock_init() can return NULL on\n   allocation failure.  The result is dereferenced unconditionally,\n   causing a kernel NULL pointer dereference.  Add a NULL check to\n   prevent the crash and clean up the bookkeeping; the VFS lock\n   itself cannot be rolled back without the allocation and will be\n   released at file or connection teardown.\n\nFix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before\nthe if(!rc) check in the UNLOCK branch so all exit paths share one\nfree site, and by freeing smb_lock and flock before goto out in the\nnon-UNLOCK branch.  Propagate the correct error code in both cases.\nFix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding\na NULL check for locks_free_lock(rlock) in the shared cleanup.\n\nFound via call-graph analysis using sqry.(CVE-2026-31477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: platform: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus' match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-31527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: require 3 sub-authorities before reading sub_auth[2]\n\nparse_dacl() compares each ACE SID against sid_unix_NFS_mode and on\nmatch reads sid.sub_auth[2] as the file mode.  If sid_unix_NFS_mode is\nthe prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares\nonly min(num_subauth, 2) sub-authorities so a client SID with\nnum_subauth = 2 and sub_auth = {88, 3} will match.\n\nIf num_subauth = 2 and the ACE is placed at the very end of the security\ndescriptor, sub_auth[2] will be  4 bytes past end_of_acl.  The\nout-of-band bytes will then be masked to the low 9 bits and applied as\nthe file's POSIX mode, probably not something that is good to have\nhappen.\n\nFix this up by forcing the SID to actually carry a third sub-authority\nbefore reading it at all.(CVE-2026-31611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate EaNameLength in smb2_get_ea()\n\nsmb2_get_ea() reads ea_req->EaNameLength from the client request and\npasses it directly to strncmp() as the comparison length without\nverifying that the length of the name really is the size of the input\nbuffer received.\n\nFix this up by properly checking the size of the name based on the value\nreceived and the overall size of the request, to prevent a later\nstrncmp() call to use the length as a "trusted" size of the buffer.\nWithout this check, uninitialized heap values might be slowly leaked to\nthe client.(CVE-2026-31612)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: use check_add_overflow() to prevent u16 DACL size overflow\n\nset_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes\nin u16 variables. When a file has many POSIX ACL entries, the\naccumulated size can wrap past 65535, causing the pointer arithmetic\n(char *)pndace + *size to land within already-written ACEs. Subsequent\nwrites then overwrite earlier entries, and pndacl->size gets a\ntruncated value.\n\nUse check_add_overflow() at each accumulation point to detect the\nwrap before it corrupts the buffer, consistent with existing\ncheck_mul_overflow() usage elsewhere in smbacl.c.(CVE-2026-31704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path\n\nsmb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL\nand the default QUERY_INFO path.  The QUERY_INFO branch clamps\nqi.input_buffer_length to the server-reported OutputBufferLength and then\ncopies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but\nit never verifies that the flexible-array payload actually fits within\nrsp_iov[1].iov_len.\n\nA malicious server can return OutputBufferLength larger than the actual\nQUERY_INFO response, causing copy_to_user() to walk past the response\nbuffer and expose adjacent kernel heap to userspace.\n\nGuard the QUERY_INFO copy with a bounds check on the actual Buffer\npayload.  Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)\nrather than an open-coded addition so the guard cannot overflow on\n32-bit builds.(CVE-2026-31708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: fix state inconsistency on gadget init failure\n\nWhen cdns3_gadget_start() fails, the DRD hardware is left in gadget mode\nwhile software state remains INACTIVE, creating hardware/software state\ninconsistency.\n\nWhen switching to host mode via sysfs:\n  echo host > /sys/class/usb_role/13180000.usb-role-switch/role\n\nThe role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error,\nso cdns_role_stop() skips cleanup because state is still INACTIVE.\nThis violates the DRD controller design specification (Figure22),\nwhich requires returning to idle state before switching roles.\n\nThis leads to a synchronous external abort in xhci_gen_setup() when\nsetting up the host controller:\n\n[  516.440698] configfs-gadget 13180000.usb: failed to start g1: -19\n[  516.442035] cdns-usb3 13180000.usb: Failed to add gadget\n[  516.443278] cdns-usb3 13180000.usb: set role 2 has failed\n...\n[ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller\n[ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP\n[ 1301.382485] pc : xhci_gen_setup+0xa4/0x408\n[ 1301.393391] backtrace:\n    ...\n    xhci_gen_setup+0xa4/0x408    <-- CRASH\n    xhci_plat_setup+0x44/0x58\n    usb_add_hcd+0x284/0x678\n    ...\n    cdns_role_set+0x9c/0xbc        <-- Role switch\n\nFix by calling cdns_drd_gadget_off() in the error path to properly\nclean up the DRD gadget state.(CVE-2026-31754)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: fix NULL pointer dereference in ep_queue\n\nWhen the gadget endpoint is disabled or not yet configured, the ep->desc\npointer can be NULL. This leads to a NULL pointer dereference when\n__cdns3_gadget_ep_queue() is called, causing a kernel crash.\n\nAdd a check to return -ESHUTDOWN if ep->desc is NULL, which is the\nstandard return code for unconfigured endpoints.\n\nThis prevents potential crashes when ep_queue is called on endpoints\nthat are not ready.(CVE-2026-31755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: move wake reason storage into validated event handlers\n\nhci_store_wake_reason() is called from hci_event_packet() immediately\nafter stripping the HCI event header but before hci_event_func()\nenforces the per-event minimum payload length from hci_ev_table.\nThis means a short HCI event frame can reach bacpy() before any bounds\ncheck runs.\n\nRather than duplicating skb parsing and per-event length checks inside\nhci_store_wake_reason(), move wake-address storage into the individual\nevent handlers after their existing event-length validation has\nsucceeded. Convert hci_store_wake_reason() into a small helper that only\nstores an already-validated bdaddr while the caller holds hci_dev_lock().\nUse the same helper after hci_event_func() with a NULL address to\npreserve the existing unexpected-wake fallback semantics when no\nvalidated event handler records a wake address.\n\nAnnotate the helper with __must_hold(&hdev->lock) and add\nlockdep_assert_held(&hdev->lock) so future call paths keep the lock\ncontract explicit.\n\nCall the helper from hci_conn_request_evt(), hci_conn_complete_evt(),\nhci_sync_conn_complete_evt(), le_conn_complete_evt(),\nhci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),\nhci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and\nhci_le_past_received_evt().(CVE-2026-31771)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Check to ensure report responses match the request\n\nIt is possible for a malicious (or clumsy) device to respond to a\nspecific report's feature request using a completely different report\nID.  This can cause confusion in the HID core resulting in nasty\nside-effects such as OOB writes.\n\nAdd a check to ensure that the report ID in the response, matches the\none that was requested.  If it doesn't, omit reporting the raw event and\nreturn early.(CVE-2026-43047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Mitigate potential OOB by removing bogus memset()\n\nThe memset() in hid_report_raw_event() has the good intention of\nclearing out bogus data by zeroing the area from the end of the incoming\ndata string to the assumed end of the buffer.  However, as we have\npreviously seen, doing so can easily result in OOB reads and writes in\nthe subsequent thread of execution.\n\nThe current suggestion from one of the HID maintainers is to remove the\nmemset() and simply return if the incoming event buffer size is not\nlarge enough to fill the associated report.\n\nSuggested-by Benjamin Tissoires <(CVE-2026-43048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEFI/CPER: don't dump the entire memory region\n\nThe current logic at cper_print_fw_err() doesn't check if the\nerror record length is big enough to handle offset. On a bad firmware,\nif the ofset is above the actual record, length -= offset will\nunderflow, making it dump the entire memory.\n\nThe end result can be:\n\n - the logic taking a lot of time dumping large regions of memory;\n - data disclosure due to the memory dumps;\n - an OOPS, if it tries to dump an unmapped memory region.\n\nFix it by checking if the section length is too small before doing\na hex dump.\n\n[ rjw: Subject tweaks ](CVE-2026-43171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE\n\nThe arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE -\nwhich is a valid index - so add a check for this.(CVE-2026-43212)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: Add support for TSV110 Spectre-BHB mitigation\n\nThe TSV110 processor is vulnerable to the Spectre-BHB (Branch History\nBuffer) attack, which can be exploited to leak information through\nbranch prediction side channels. This commit adds the MIDR of TSV110\nto the list for software mitigation.(CVE-2026-43261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Limit the length of unkillable synchronous timeouts\n\nThe usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.\n\nTo prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.\n\nIn addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Prevent interrupt storm on host controller error (HCE)\n\nThe xHCI controller reports a Host Controller Error (HCE) in UAS Storage\nDevice plug/unplug scenarios on Android devices. HCE is checked in\nxhci_irq() function and causes an interrupt storm (since the interrupt\nisn’t cleared), leading to severe system-level faults.\n\nWhen the xHC controller reports HCE in the interrupt handler, the driver\nonly logs a warning and assumes xHC activity will stop as stated in xHCI\nspecification. An interrupt storm does however continue on some hosts\neven after HCE, and only ceases after manually disabling xHC interrupt\nand stopping the controller by calling xhci_halt().\n\nAdd xhci_halt() to xhci_irq() function where STS_HCE status is checked,\nmirroring the existing error handling pattern used for STS_FATAL errors.\n\nThis only fixes the interrupt storm. Proper HCE recovery requires resetting\nand re-initializing the xHC.(CVE-2026-43488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptrace: slightly saner 'get_dumpable()' logic\n\nThe 'dumpability' of a task is fundamentally about the memory image of\nthe task - the concept comes from whether it can core dump or not - and\nmakes no sense when you don't have an associated mm.\n\nAnd almost all users do in fact use it only for the case where the task\nhas a mm pointer.\n\nBut we have one odd special case: ptrace_may_access() uses 'dumpable' to\ncheck various other things entirely independently of the MM (typically\nexplicitly using flags like PTRACE_MODE_READ_FSCREDS).  Including for\nthreads that no longer have a VM (and maybe never did, like most kernel\nthreads).\n\nIt's not what this flag was designed for, but it is what it is.\n\nThe ptrace code does check that the uid/gid matches, so you do have to\nbe uid-0 to see kernel thread details, but this means that the\ntraditional "drop capabilities" model doesn't make any difference for\nthis all.\n\nMake it all make a *bit* more sense by saying that if you don't have a\nMM pointer, we'll use a cached "last dumpability" flag if the thread\never had a MM (it will be zero for kernel threads since it is never\nset), and require a proper CAP_SYS_PTRACE capability to override.(CVE-2026-46333)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-315.0.0.218.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","perf-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-315.0.0.218.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","perf-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2416"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38488"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39841"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40261"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40324"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68185"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68214"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68288"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68820"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71064"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23273"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31393"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31447"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31527"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31611"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31612"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31704"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31708"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31754"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31755"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31771"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43047"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43048"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43171"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43212"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43261"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43428"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43488"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46333"}],"database_specific":{"severity":"High"}}