{"id":"OESA-2026-1950","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\nbtrfs: fix extent map use-after-free when handling missing device in read_one_chunk\n\nStore the error code before freeing the extent_map. Though it's\nreference counted structure, in that function it's the first and last\nallocation so this would lead to a potential use-after-free.\n\nThe error can happen eg. when chunk is stored on a missing device and\nthe degraded mount option is missing.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721(CVE-2022-50300)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix locking in pdc_iodc_print() firmware call\n\nUtilize pdc_lock spinlock to protect parallel modifications of the\niodc_dbuf[] buffer, check length to prevent buffer overflow of\niodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong\nindentings.(CVE-2022-50518)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Add length check in indx_get_root\n\nThis adds a length check to guarantee the retrieved index root is legit.\n\n[  162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320\n[  162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243\n[  162.460851]\n[  162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42\n[  162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[  162.462609] Call Trace:\n[  162.462954]  <TASK>\n[  162.463276]  dump_stack_lvl+0x49/0x63\n[  162.463822]  print_report.cold+0xf5/0x689\n[  162.464608]  ? unwind_get_return_address+0x3a/0x60\n[  162.465766]  ? hdr_find_e.isra.0+0x10c/0x320\n[  162.466975]  kasan_report+0xa7/0x130\n[  162.467506]  ? _raw_spin_lock_irq+0xc0/0xf0\n[  162.467998]  ? hdr_find_e.isra.0+0x10c/0x320\n[  162.468536]  __asan_load2+0x68/0x90\n[  162.468923]  hdr_find_e.isra.0+0x10c/0x320\n[  162.469282]  ? cmp_uints+0xe0/0xe0\n[  162.469557]  ? cmp_sdh+0x90/0x90\n[  162.469864]  ? ni_find_attr+0x214/0x300\n[  162.470217]  ? ni_load_mi+0x80/0x80\n[  162.470479]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  162.470931]  ? ntfs_bread_run+0x190/0x190\n[  162.471307]  ? indx_get_root+0xe4/0x190\n[  162.471556]  ? indx_get_root+0x140/0x190\n[  162.471833]  ? indx_init+0x1e0/0x1e0\n[  162.472069]  ? fnd_clear+0x115/0x140\n[  162.472363]  ? _raw_spin_lock_irqsave+0x100/0x100\n[  162.472731]  indx_find+0x184/0x470\n[  162.473461]  ? sysvec_apic_timer_interrupt+0x57/0xc0\n[  162.474429]  ? indx_find_buffer+0x2d0/0x2d0\n[  162.474704]  ? do_syscall_64+0x3b/0x90\n[  162.474962]  dir_search_u+0x196/0x2f0\n[  162.475381]  ? ntfs_nls_to_utf16+0x450/0x450\n[  162.475661]  ? ntfs_security_init+0x3d6/0x440\n[  162.475906]  ? is_sd_valid+0x180/0x180\n[  162.476191]  ntfs_extend_init+0x13f/0x2c0\n[  162.476496]  ? ntfs_fix_post_read+0x130/0x130\n[  162.476861]  ? iput.part.0+0x286/0x320\n[  162.477325]  ntfs_fill_super+0x11e0/0x1b50\n[  162.477709]  ? put_ntfs+0x1d0/0x1d0\n[  162.477970]  ? vsprintf+0x20/0x20\n[  162.478258]  ? set_blocksize+0x95/0x150\n[  162.478538]  get_tree_bdev+0x232/0x370\n[  162.478789]  ? put_ntfs+0x1d0/0x1d0\n[  162.479038]  ntfs_fs_get_tree+0x15/0x20\n[  162.479374]  vfs_get_tree+0x4c/0x130\n[  162.479729]  path_mount+0x654/0xfe0\n[  162.480124]  ? putname+0x80/0xa0\n[  162.480484]  ? finish_automount+0x2e0/0x2e0\n[  162.480894]  ? putname+0x80/0xa0\n[  162.481467]  ? kmem_cache_free+0x1c4/0x440\n[  162.482280]  ? putname+0x80/0xa0\n[  162.482714]  do_mount+0xd6/0xf0\n[  162.483264]  ? path_mount+0xfe0/0xfe0\n[  162.484782]  ? __kasan_check_write+0x14/0x20\n[  162.485593]  __x64_sys_mount+0xca/0x110\n[  162.486024]  do_syscall_64+0x3b/0x90\n[  162.486543]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  162.487141] RIP: 0033:0x7f9d374e948a\n[  162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[  162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5\n[  162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a\n[  162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0\n[  162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020\n[  162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0\n[  162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff\n[  162.493644]  </TASK>\n[  162.493908]\n[  162.494214] The buggy address belongs to the physical page:\n[  162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc\n[  162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n[  162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000\n[  162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000\n[  162.500542] page dumped becau\n---truncated---(CVE-2023-53194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrpl: Fix use-after-free in rpl_do_srh_inline().\n\nRunning lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers\nthe splat below [0].\n\nrpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after\nskb_cow_head(), which is illegal as the header could be freed then.\n\nLet's fix it by making oldhdr to a local struct instead of a pointer.\n\n[0]:\n[root@fedora net]# ./lwt_dst_cache_ref_loop.sh\n...\nTEST: rpl (input)\n[   57.631529] ==================================================================\nBUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)\nRead of size 40 at addr ffff888122bf96d8 by task ping6/1543\n\nCPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n <IRQ>\n dump_stack_lvl (lib/dump_stack.c:122)\n print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)\n kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)\n kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))\n __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))\n rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)\n rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)\n lwtunnel_input (net/core/lwtunnel.c:459)\n ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))\n __netif_receive_skb_one_core (net/core/dev.c:5967)\n process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)\n __napi_poll.constprop.0 (net/core/dev.c:7452)\n net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)\n handle_softirqs (kernel/softirq.c:579)\n do_softirq (kernel/softirq.c:480 (discriminator 20))\n </IRQ>\n <TASK>\n __local_bh_enable_ip (kernel/softirq.c:407)\n __dev_queue_xmit (net/core/dev.c:4740)\n ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)\n ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)\n ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)\n ip6_send_skb (net/ipv6/ip6_output.c:1983)\n rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)\n __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))\n __x64_sys_sendto (net/socket.c:2231)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\nRIP: 0033:0x7f68cffb2a06\nCode: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08\nRSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06\nRDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003\nRBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4\nR13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0\n </TASK>\n\nAllocated by task 1543:\n kasan_save_stack (mm/kasan/common.c:48)\n kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))\n __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)\n kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)\n kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))\n __alloc_skb (net/core/skbuff.c:669)\n __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))\n ip6_\n---truncated---(CVE-2025-38476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: tegra: Use I/O memcpy to write to IRAM\n\nKasan crashes the kernel trying to check boundaries when using the\nnormal memcpy.(CVE-2025-39794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: avoid potential out-of-bounds in btrfs_encode_fh()\n\nThe function btrfs_encode_fh() does not properly account for the three\ncases it handles.\n\nBefore writing to the file handle (fh), the function only returns to the\nuser BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or\nBTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).\n\nHowever, when a parent exists and the root ID of the parent and the\ninode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT\n(10 dwords, 40 bytes).\n\nIf *max_len is not large enough, this write goes out of bounds because\nBTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than\nBTRFS_FID_SIZE_CONNECTABLE originally returned.\n\nThis results in an 8-byte out-of-bounds write at\nfid->parent_root_objectid = parent_root_id.\n\nA previous attempt to fix this issue was made but was lost.\n\nhttps://lore.kernel.org/all/(CVE-2025-40205)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-core: fix wrong reinitialization of ringbuffer on reopen\n\ndvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the\nDVR device.  dvb_ringbuffer_init() calls init_waitqueue_head(), which\nreinitializes the waitqueue list head to empty.\n\nSince dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the\nsame DVR device share it), this orphans any existing waitqueue entries\nfrom io_uring poll or epoll, leaving them with stale prev/next pointers\nwhile the list head is reset to {self, self}.\n\nThe waitqueue and spinlock in dvr_buffer are already properly\ninitialized once in dvb_dmxdev_init().  The open path only needs to\nreset the buffer data pointer, size, and read/write positions.\n\nReplace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct\nassignment of data/size and a call to dvb_ringbuffer_reset(), which\nproperly resets pread, pwrite, and error with correct memory ordering\nwithout touching the waitqueue or spinlock.(CVE-2026-23253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: validate DFA start states are in bounds in unpack_pdb\n\nStart states are read from untrusted data and used as indexes into the\nDFA state tables. The aa_dfa_next() function call in unpack_pdb() will\naccess dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds\nthe number of states in the DFA, this results in an out-of-bound read.\n\n==================================================================\n BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360\n Read of size 4 at addr ffff88811956fb90 by task su/1097\n ...\n\nReject policies with out-of-bounds start states during unpacking\nto prevent the issue.(CVE-2026-23269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix memory leak in ice_set_ringparam()\n\nIn ice_set_ringparam, tx_rings and xdp_rings are allocated before\nrx_rings. If the allocation of rx_rings fails, the code jumps to\nthe done label leaking both tx_rings and xdp_rings. Furthermore, if\nthe setup of an individual Rx ring fails during the loop, the code jumps\nto the free_tx label which releases tx_rings but leaks xdp_rings.\n\nFix this by introducing a free_xdp label and updating the error paths to\nensure both xdp_rings and tx_rings are properly freed if rx_rings\nallocation or setup fails.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-23389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: replace recursive profile removal with iterative approach\n\nThe profile removal code uses recursion when removing nested profiles,\nwhich can lead to kernel stack exhaustion and system crashes.\n\nReproducer:\n  $ pf='a'; for ((i=0; i<1024; i++)); do\n      echo -e "profile $pf { \\n }" | apparmor_parser -K -a;\n      pf="$pf//x";\n  done\n  $ echo -n a > /sys/kernel/security/apparmor/.remove\n\nReplace the recursive __aa_profile_list_release() approach with an\niterative approach in __remove_profile(). The function repeatedly\nfinds and removes leaf profiles until the entire subtree is removed,\nmaintaining the same removal semantic without recursion.(CVE-2026-23404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix: limit the number of levels of policy namespaces\n\nCurrently the number of policy namespaces is not bounded relying on\nthe user namespace limit. However policy namespaces aren't strictly\ntied to user namespaces and it is possible to create them and nest\nthem arbitrarily deep which can be used to exhaust system resource.\n\nHard cap policy namespaces to the same depth as user namespaces.(CVE-2026-23405)\n\nA vulnerability exists in the AppArmor security module of the Linux kernel, stemming from a side-effect bug in the usage of the match_char macro. This macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the Deterministic Finite Automaton (DFA) to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. This vulnerability may impact the confidentiality of the kernel.(CVE-2026-23406)\n\nAn out-of-bounds read and write vulnerability exists in the AppArmor security module of the Linux kernel. In the verify_dfa() function, while traversing the differential encoding chain, it reads `k = DEFAULT_TABLE[j]` and uses `k` as an array index without validating whether `k` is within the bounds of the valid state count (state_count). If an attacker can supply a malicious Deterministic Finite Automaton (DFA) with a crafted value where `DEFAULT_TABLE[j] >= state_count`, it will lead to out-of-bounds reads and writes. This vulnerability may impact the confidentiality and stability of the kernel.(CVE-2026-23407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: Fix double free of ns_name in aa_replace_profiles()\n\nif ns_name is NULL after\n1071         error = aa_unpack(udata, &lh, &ns_name);\n\nand if ent->ns_name contains an ns_name in\n1089                 } else if (ent->ns_name) {\n\nthen ns_name is assigned the ent->ns_name\n1095                         ns_name = ent->ns_name;\n\nhowever ent->ns_name is freed at\n1262                 aa_load_ent_free(ent);\n\nand then again when freeing ns_name at\n1270         kfree(ns_name);\n\nFix this by NULLing out ent->ns_name after it is transferred to ns_name\n\n")(CVE-2026-23408)\n\nA race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)\n\nA vulnerability exists in the AppArmor security module of the Linux kernel when handling the i_private field of the inode structure. AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor's access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM: runtime: Fix a race condition related to device removal\n\nThe following code in pm_runtime_work() may dereference the dev->parent\npointer after the parent device has been freed:\n\n\t/* Maybe the parent is now able to suspend. */\n\tif (parent && !parent->power.ignore_children) {\n\t\tspin_unlock(&dev->power.lock);\n\n\t\tspin_lock(&parent->power.lock);\n\t\trpm_idle(parent, RPM_ASYNC);\n\t\tspin_unlock(&parent->power.lock);\n\n\t\tspin_lock(&dev->power.lock);\n\t}\n\nFix this by inserting a flush_work() call in pm_runtime_remove().\n\nWithout this patch blktest block/001 triggers the following complaint\nsporadically:\n\nBUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160\nRead of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081\nWorkqueue: pm pm_runtime_work\nCall Trace:\n <TASK>\n dump_stack_lvl+0x61/0x80\n print_address_description.constprop.0+0x8b/0x310\n print_report+0xfd/0x1d7\n kasan_report+0xd8/0x1d0\n __kasan_check_byte+0x42/0x60\n lock_acquire.part.0+0x38/0x230\n lock_acquire+0x70/0x160\n _raw_spin_lock+0x36/0x50\n rpm_suspend+0xc6a/0xfe0\n rpm_idle+0x578/0x770\n pm_runtime_work+0xee/0x120\n process_one_work+0xde3/0x1410\n worker_thread+0x5eb/0xfe0\n kthread+0x37b/0x480\n ret_from_fork+0x6cb/0x920\n ret_from_fork_asm+0x11/0x20\n </TASK>\n\nAllocated by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_alloc_info+0x3d/0x50\n __kasan_kmalloc+0xa0/0xb0\n __kmalloc_noprof+0x311/0x990\n scsi_alloc_target+0x122/0xb60 [scsi_mod]\n __scsi_scan_target+0x101/0x460 [scsi_mod]\n scsi_scan_channel+0x179/0x1c0 [scsi_mod]\n scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]\n store_scan+0x2d2/0x390 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810\n do_syscall_64+0xee/0xfc0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFreed by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_free_info+0x3f/0x50\n __kasan_slab_free+0x67/0x80\n kfree+0x225/0x6c0\n scsi_target_dev_release+0x3d/0x60 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_put+0x7f/0xc0 [scsi_mod]\n sdev_store_delete+0xa5/0x120 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810(CVE-2026-23452)\n\nIn the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen/privcmd: restrict usage in unprivileged domU\n\nThe Xen privcmd driver allows to issue arbitrary hypercalls from\nuser space processes. This is normally no problem, as access is\nusually limited to root and the hypervisor will deny any hypercalls\naffecting other domains.\n\nIn case the guest is booted using secure boot, however, the privcmd\ndriver would be enabling a root user process to modify e.g. kernel\nmemory contents, thus breaking the secure boot feature.\n\nThe only known case where an unprivileged domU is really needing to\nuse the privcmd driver is the case when it is acting as the device\nmodel for another guest. In this case all hypercalls issued via the\nprivcmd driver will target that other guest.\n\nFortunately the privcmd driver can already be locked down to allow\nonly hypercalls targeting a specific domain, but this mode can be\nactivated from user land only today.\n\nThe target domain can be obtained from Xenstore, so when not running\nin dom0 restrict the privcmd driver to that target domain from the\nbeginning, resolving the potential problem of breaking secure boot.\n\nThis is XSA-482\n\n---\nV2:\n- defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich)\n- wait in open() if target domain isn't known yet\n- issue message in case no target domain found (Jan Beulich)(CVE-2026-31788)","modified":"2026-04-17T13:20:08.600730Z","published":"2026-04-17T13:01:56Z","upstream":["CVE-2022-50300","CVE-2022-50518","CVE-2023-53194","CVE-2025-38476","CVE-2025-39794","CVE-2025-40205","CVE-2026-23253","CVE-2026-23269","CVE-2026-23389","CVE-2026-23404","CVE-2026-23405","CVE-2026-23406","CVE-2026-23407","CVE-2026-23408","CVE-2026-23410","CVE-2026-23411","CVE-2026-23452","CVE-2026-31408","CVE-2026-31788"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1950"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50300"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50518"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53194"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39794"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40205"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23253"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23269"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23389"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23404"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23405"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23406"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23407"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23410"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23411"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23452"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31788"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-309.0.0.212.oe2203sp4"}]}],"ecosystem_specific":{"x86_64":["bpftool-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","perf-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm"],"aarch64":["bpftool-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","perf-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-309.0.0.212.oe2203sp4.src.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-1950.json"}}],"schema_version":"1.7.5"}