{"schema_version":"1.7.2","id":"OESA-2026-2176","modified":"2026-05-03T09:57:32Z","published":"2026-05-03T09:57:32Z","upstream":["CVE-2025-27558","CVE-2025-71089","CVE-2026-23096","CVE-2026-23378","CVE-2026-23398","CVE-2026-23406","CVE-2026-23407","CVE-2026-23442","CVE-2026-23447","CVE-2026-23449","CVE-2026-23452","CVE-2026-23455","CVE-2026-23456","CVE-2026-23457","CVE-2026-23458","CVE-2026-23475","CVE-2026-31389","CVE-2026-31415","CVE-2026-31416","CVE-2026-31427","CVE-2026-31428","CVE-2026-31431"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.(CVE-2025-27558)\n\nIn the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuacce: fix cdev handling in the cleanup path\n\nWhen cdev_device_add fails, it internally releases the cdev memory,\nand if cdev_device_del is then executed, it will cause a hang error.\nTo fix it, we check the return value of cdev_device_add() and clear\nuacce->cdev to avoid calling cdev_device_del in the uacce_remove.(CVE-2026-23096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ife: Fix metalist update behavior\n\nWhenever an ife action replace changes the metalist, instead of\nreplacing the old data on the metalist, the current ife code is appending\nthe new metadata. Aside from being innapropriate behavior, this may lead\nto an unbounded addition of metadata to the metalist which might cause an\nout of bounds error when running the encode op:\n\n[  138.423369][    C1] ==================================================================\n[  138.424317][    C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)\n[  138.424906][    C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255\n[  138.425778][    C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)\n[  138.425795][    C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[  138.425800][    C1] Call Trace:\n[  138.425804][    C1]  <IRQ>\n[  138.425808][    C1]  dump_stack_lvl (lib/dump_stack.c:122)\n[  138.425828][    C1]  print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[  138.425839][    C1]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  138.425844][    C1]  ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))\n[  138.425853][    C1]  ? ife_tlv_meta_encode (net/ife/ife.c:168)\n[  138.425859][    C1]  kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597)\n[  138.425868][    C1]  ? ife_tlv_meta_encode (net/ife/ife.c:168)\n[  138.425878][    C1]  kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1))\n[  138.425884][    C1]  __asan_memset (mm/kasan/shadow.c:84 (discriminator 2))\n[  138.425889][    C1]  ife_tlv_meta_encode (net/ife/ife.c:168)\n[  138.425893][    C1]  ? ife_tlv_meta_encode (net/ife/ife.c:171)\n[  138.425898][    C1]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  138.425903][    C1]  ife_encode_meta_u16 (net/sched/act_ife.c:57)\n[  138.425910][    C1]  ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114)\n[  138.425916][    C1]  ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3))\n[  138.425921][    C1]  ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45)\n[  138.425927][    C1]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  138.425931][    C1]  tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)\n\nTo solve this issue, fix the replace behavior by adding the metalist to\nthe ife rcu data structure.(CVE-2026-23378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nicmp: fix NULL pointer dereference in icmp_tag_validation()\n\nicmp_tag_validation() unconditionally dereferences the result of\nrcu_dereference(inet_protos[proto]) without checking for NULL.\nThe inet_protos[] array is sparse -- only about 15 of 256 protocol\nnumbers have registered handlers. When ip_no_pmtu_disc is set to 3\n(hardened PMTU mode) and the kernel receives an ICMP Fragmentation\nNeeded error with a quoted inner IP header containing an unregistered\nprotocol number, the NULL dereference causes a kernel panic in\nsoftirq context.\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143)\n Call Trace:\n  <IRQ>\n  icmp_rcv (net/ipv4/icmp.c:1527)\n  ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)\n  ip_local_deliver_finish (net/ipv4/ip_input.c:242)\n  ip_local_deliver (net/ipv4/ip_input.c:262)\n  ip_rcv (net/ipv4/ip_input.c:573)\n  __netif_receive_skb_one_core (net/core/dev.c:6164)\n  process_backlog (net/core/dev.c:6628)\n  handle_softirqs (kernel/softirq.c:561)\n  </IRQ>\n\nAdd a NULL check before accessing icmp_strict_tag_validation. If the\nprotocol has no registered handler, return false since it cannot\nperform strict tag validation.(CVE-2026-23398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix side-effect bug in match_char() macro usage\n\nThe match_char() macro evaluates its character parameter multiple\ntimes when traversing differential encoding chains. When invoked\nwith *str++, the string pointer advances on each iteration of the\ninner do-while loop, causing the DFA to check different characters\nat each iteration and therefore skip input characters.\nThis results in out-of-bounds reads when the pointer advances past\nthe input buffer boundary.\n\n[   94.984676] ==================================================================\n[   94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760\n[   94.985655] Read of size 1 at addr ffff888100342000 by task file/976\n\n[   94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)\n[   94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[   94.986329] Call Trace:\n[   94.986341]  <TASK>\n[   94.986347]  dump_stack_lvl+0x5e/0x80\n[   94.986374]  print_report+0xc8/0x270\n[   94.986384]  ? aa_dfa_match+0x5ae/0x760\n[   94.986388]  kasan_report+0x118/0x150\n[   94.986401]  ? aa_dfa_match+0x5ae/0x760\n[   94.986405]  aa_dfa_match+0x5ae/0x760\n[   94.986408]  __aa_path_perm+0x131/0x400\n[   94.986418]  aa_path_perm+0x219/0x2f0\n[   94.986424]  apparmor_file_open+0x345/0x570\n[   94.986431]  security_file_open+0x5c/0x140\n[   94.986442]  do_dentry_open+0x2f6/0x1120\n[   94.986450]  vfs_open+0x38/0x2b0\n[   94.986453]  ? may_open+0x1e2/0x2b0\n[   94.986466]  path_openat+0x231b/0x2b30\n[   94.986469]  ? __x64_sys_openat+0xf8/0x130\n[   94.986477]  do_file_open+0x19d/0x360\n[   94.986487]  do_sys_openat2+0x98/0x100\n[   94.986491]  __x64_sys_openat+0xf8/0x130\n[   94.986499]  do_syscall_64+0x8e/0x660\n[   94.986515]  ? count_memcg_events+0x15f/0x3c0\n[   94.986526]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   94.986540]  ? handle_mm_fault+0x1639/0x1ef0\n[   94.986551]  ? vma_start_read+0xf0/0x320\n[   94.986558]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   94.986561]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   94.986563]  ? fpregs_assert_state_consistent+0x50/0xe0\n[   94.986572]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   94.986574]  ? arch_exit_to_user_mode_prepare+0x9/0xb0\n[   94.986587]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   94.986588]  ? irqentry_exit+0x3c/0x590\n[   94.986595]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   94.986597] RIP: 0033:0x7fda4a79c3ea\n\nFix by extracting the character value before invoking match_char,\nensuring single evaluation per outer loop.(CVE-2026-23406)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix missing bounds check on DEFAULT table in verify_dfa()\n\nThe verify_dfa() function only checks DEFAULT_TABLE bounds when the state\nis not differentially encoded.\n\nWhen the verification loop traverses the differential encoding chain,\nit reads k = DEFAULT_TABLE[j] and uses k as an array index without\nvalidation. A malformed DFA with DEFAULT_TABLE[j] >= state_count,\ntherefore, causes both out-of-bounds reads and writes.\n\n[   57.179855] ==================================================================\n[   57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660\n[   57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993\n\n[   57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)\n[   57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[   57.181563] Call Trace:\n[   57.181572]  <TASK>\n[   57.181577]  dump_stack_lvl+0x5e/0x80\n[   57.181596]  print_report+0xc8/0x270\n[   57.181605]  ? verify_dfa+0x59a/0x660\n[   57.181608]  kasan_report+0x118/0x150\n[   57.181620]  ? verify_dfa+0x59a/0x660\n[   57.181623]  verify_dfa+0x59a/0x660\n[   57.181627]  aa_dfa_unpack+0x1610/0x1740\n[   57.181629]  ? __kmalloc_cache_noprof+0x1d0/0x470\n[   57.181640]  unpack_pdb+0x86d/0x46b0\n[   57.181647]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   57.181653]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   57.181656]  ? aa_unpack_nameX+0x1a8/0x300\n[   57.181659]  aa_unpack+0x20b0/0x4c30\n[   57.181662]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   57.181664]  ? stack_depot_save_flags+0x33/0x700\n[   57.181681]  ? kasan_save_track+0x4f/0x80\n[   57.181683]  ? kasan_save_track+0x3e/0x80\n[   57.181686]  ? __kasan_kmalloc+0x93/0xb0\n[   57.181688]  ? __kvmalloc_node_noprof+0x44a/0x780\n[   57.181693]  ? aa_simple_write_to_buffer+0x54/0x130\n[   57.181697]  ? policy_update+0x154/0x330\n[   57.181704]  aa_replace_profiles+0x15a/0x1dd0\n[   57.181707]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   57.181710]  ? __kvmalloc_node_noprof+0x44a/0x780\n[   57.181712]  ? aa_loaddata_alloc+0x77/0x140\n[   57.181715]  ? srso_alias_return_thunk+0x5/0xfbef5\n[   57.181717]  ? _copy_from_user+0x2a/0x70\n[   57.181730]  policy_update+0x17a/0x330\n[   57.181733]  profile_replace+0x153/0x1a0\n[   57.181735]  ? rw_verify_area+0x93/0x2d0\n[   57.181740]  vfs_write+0x235/0xab0\n[   57.181745]  ksys_write+0xb0/0x170\n[   57.181748]  do_syscall_64+0x8e/0x660\n[   57.181762]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   57.181765] RIP: 0033:0x7f6192792eb2\n\nRemove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE\nentries unconditionally.(CVE-2026-23407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences.(CVE-2026-23442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check\n\nThe same bounds-check bug fixed for NDP16 in the previous patch also\nexists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated\nagainst the total skb length without accounting for ndpoffset, allowing\nout-of-bounds reads when the NDP32 is placed near the end of the NTB.\n\nAdd ndpoffset to the nframes bounds check and use struct_size_t() to\nexpress the NDP-plus-DPE-array size more clearly.\n\nCompile-tested only.(CVE-2026-23447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: teql: Fix double-free in teql_master_xmit\n\nWhenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should\nbe called using the seq_lock to avoid racing with the datapath. Failure\nto do so may cause crashes like the following:\n\n[  238.028993][  T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)\n[  238.029328][  T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318\n[  238.029749][  T318]\n[  238.029900][  T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full)\n[  238.029906][  T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[  238.029910][  T318] Call Trace:\n[  238.029913][  T318]  <TASK>\n[  238.029916][  T318]  dump_stack_lvl (lib/dump_stack.c:122)\n[  238.029928][  T318]  print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[  238.029940][  T318]  ? skb_release_data (net/core/skbuff.c:1139)\n[  238.029944][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[  238.029957][  T318]  ? skb_release_data (net/core/skbuff.c:1139)\n[  238.029969][  T318]  kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)\n[  238.029979][  T318]  ? skb_release_data (net/core/skbuff.c:1139)\n[  238.029989][  T318]  check_slab_allocation (mm/kasan/common.c:231)\n[  238.029995][  T318]  kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1))\n[  238.030004][  T318]  skb_release_data (net/core/skbuff.c:1139)\n...\n[  238.030025][  T318]  sk_skb_reason_drop (net/core/skbuff.c:1256)\n[  238.030032][  T318]  pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)\n[  238.030039][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[  238.030054][  T318]  qdisc_reset (net/sched/sch_generic.c:1034)\n[  238.030062][  T318]  teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)\n[  238.030071][  T318]  __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)\n[  238.030077][  T318]  qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)\n[  238.030089][  T318]  ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)\n[  238.030095][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  238.030102][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  238.030106][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  238.030114][  T318]  tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)\n...\n[  238.072958][  T318] Allocated by task 303 on cpu 5 at 238.026275s:\n[  238.073392][  T318]  kasan_save_stack (mm/kasan/common.c:58)\n[  238.073884][  T318]  kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[  238.074230][  T318]  __kasan_slab_alloc (mm/kasan/common.c:369)\n[  238.074578][  T318]  kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921)\n[  238.076091][  T318]  kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))\n[  238.076450][  T318]  __alloc_skb (net/core/skbuff.c:713)\n[  238.076834][  T318]  alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)\n[  238.077178][  T318]  sock_alloc_send_pskb (net/core/sock.c:2997)\n[  238.077520][  T318]  packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108)\n[  238.081469][  T318]\n[  238.081870][  T318] Freed by task 299 on cpu 1 at 238.028496s:\n[  238.082761][  T318]  kasan_save_stack (mm/kasan/common.c:58)\n[  238.083481][  T318]  kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[  238.085348][  T318]  kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))\n[  238.085900][  T318]  __kasan_slab_free (mm/\n---truncated---(CVE-2026-23449)\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 following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: check for zero length in DecodeQ931()\n\nIn DecodeQ931(), the UserUserIE code path reads a 16-bit length from\nthe packet, then decrements it by 1 to skip the protocol discriminator\nbyte before passing it to DecodeH323_UserInformation(). If the encoded\nlength is 0, the decrement wraps to -1, which is then passed as a\nlarge value to the decoder, leading to an out-of-bounds read.\n\nAdd a check to ensure len is positive after the decrement.(CVE-2026-23455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case\n\nIn decode_int(), the CONS case calls get_bits(bs, 2) to read a length\nvalue, then calls get_uint(bs, len) without checking that len bytes\nremain in the buffer. The existing boundary check only validates the\n2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()\nreads. This allows a malformed H.323/RAS packet to cause a 1-4 byte\nslab-out-of-bounds read.\n\nAdd a boundary check for len bytes after get_bits() and before\nget_uint().(CVE-2026-23456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()\n\nsip_help_tcp() parses the SIP Content-Length header with\nsimple_strtoul(), which returns unsigned long, but stores the result in\nunsigned int clen.  On 64-bit systems, values exceeding UINT_MAX are\nsilently truncated before computing the SIP message boundary.\n\nFor example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,\ncausing the parser to miscalculate where the current message ends.  The\nloop then treats trailing data in the TCP segment as a second SIP\nmessage and processes it through the SDP parser.\n\nFix this by changing clen to unsigned long to match the return type of\nsimple_strtoul(), and reject Content-Length values that exceed the\nremaining TCP payload length.(CVE-2026-23457)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()\n\nctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the\nnetlink dump callback ctnetlink_exp_ct_dump_table(), but drops the\nconntrack reference immediately after netlink_dump_start().  When the\ndump spans multiple rounds, the second recvmsg() triggers the dump\ncallback which dereferences the now-freed conntrack via nfct_help(ct),\nleading to a use-after-free on ct->ext.\n\nThe bug is that the netlink_dump_control has no .start or .done\ncallbacks to manage the conntrack reference across dump rounds.  Other\ndump functions in the same file (e.g. ctnetlink_get_conntrack) properly\nuse .start/.done callbacks for this purpose.\n\nFix this by adding .start and .done callbacks that hold and release the\nconntrack reference for the duration of the dump, and move the\nnfct_help() call after the cb->args[0] early-return check in the dump\ncallback to avoid dereferencing ct->ext unnecessarily.\n\n BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0\n Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133\n\n CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY\n Call Trace:\n  <TASK>\n  ctnetlink_exp_ct_dump_table+0x4f/0x2e0\n  netlink_dump+0x333/0x880\n  netlink_recvmsg+0x3e2/0x4b0\n  ? aa_sk_perm+0x184/0x450\n  sock_recvmsg+0xde/0xf0\n\n Allocated by task 133:\n  kmem_cache_alloc_noprof+0x134/0x440\n  __nf_conntrack_alloc+0xa8/0x2b0\n  ctnetlink_create_conntrack+0xa1/0x900\n  ctnetlink_new_conntrack+0x3cf/0x7d0\n  nfnetlink_rcv_msg+0x48e/0x510\n  netlink_rcv_skb+0xc9/0x1f0\n  nfnetlink_rcv+0xdb/0x220\n  netlink_unicast+0x3ec/0x590\n  netlink_sendmsg+0x397/0x690\n  __sys_sendmsg+0xf4/0x180\n\n Freed by task 0:\n  slab_free_after_rcu_debug+0xad/0x1e0\n  rcu_core+0x5c3/0x9c0(CVE-2026-23458)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fix statistics allocation\n\nThe controller per-cpu statistics is not allocated until after the\ncontroller has been registered with driver core, which leaves a window\nwhere accessing the sysfs attributes can trigger a NULL-pointer\ndereference.\n\nFix this by moving the statistics allocation to controller allocation\nwhile tying its lifetime to that of the controller (rather than using\nimplicit devres).(CVE-2026-23475)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fix use-after-free on controller registration failure\n\nMake sure to deregister from driver core also in the unlikely event that\nper-cpu statistics allocation fails during controller registration to\navoid use-after-free (of driver resources) and unclocked register\naccesses.(CVE-2026-31389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: avoid overflows in ip6_datagram_send_ctl()\n\nYiming Qian reported :\n<quote>\n I believe I found a locally triggerable kernel bug in the IPv6 sendmsg\n ancillary-data path that can panic the kernel via `skb_under_panic()`\n (local DoS).\n\n The core issue is a mismatch between:\n\n - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type\n `__u16`) and\n - a pointer to the *last* provided destination-options header (`opt->dst1opt`)\n\n when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided.\n\n - `include/net/ipv6.h`:\n   - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible).\n (lines 291-307, especially 298)\n - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`:\n   - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen`\n without rejecting duplicates. (lines 909-933)\n - `net/ipv6/ip6_output.c:__ip6_append_data()`:\n   - Uses `opt->opt_flen + opt->opt_nflen` to compute header\n sizes/headroom decisions. (lines 1448-1466, especially 1463-1465)\n - `net/ipv6/ip6_output.c:__ip6_make_skb()`:\n   - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero.\n (lines 1930-1934)\n - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`:\n   - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the\n pointed-to header). (lines 1179-1185 and 1206-1211)\n\n 1. `opt_flen` is a 16-bit accumulator:\n\n - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`.\n\n 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs\n and increments `opt_flen` each time:\n\n - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`:\n   - It computes `len = ((hdr->hdrlen + 1) << 3);`\n   - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns,\n CAP_NET_RAW)`. (line 922)\n   - Then it does:\n     - `opt->opt_flen += len;` (line 927)\n     - `opt->dst1opt = hdr;` (line 928)\n\n There is no duplicate rejection here (unlike the legacy\n `IPV6_2292DSTOPTS` path which rejects duplicates at\n `net/ipv6/datagram.c:901-904`).\n\n If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps\n while `dst1opt` still points to a large (2048-byte)\n destination-options header.\n\n In the attached PoC (`poc.c`):\n\n - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048`\n - 1 cmsg with `hdrlen=0` => `len = 8`\n - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8`\n - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header.\n\n 3. The transmit path sizes headers using the wrapped `opt_flen`:\n\n- In `net/ipv6/ip6_output.c:1463-1465`:\n  - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen +\n opt->opt_nflen : 0) + ...;`\n\n With wrapped `opt_flen`, `headersize`/headroom decisions underestimate\n what will be pushed later.\n\n 4. When building the final skb, the actual push length comes from\n `dst1opt` and is not limited by wrapped `opt_flen`:\n\n - In `net/ipv6/ip6_output.c:1930-1934`:\n   - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);`\n - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes\n `dst1opt` via `ipv6_push_exthdr()`.\n - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does:\n   - `skb_push(skb, ipv6_optlen(opt));`\n   - `memcpy(h, opt, ipv6_optlen(opt));`\n\n With insufficient headroom, `skb_push()` underflows and triggers\n `skb_under_panic()` -> `BUG()`:\n\n - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`)\n - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`)\n\n - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target\n netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`).\n - Root (or any task with `CAP_NET_RAW`) can trigger this without user\n namespaces.\n - An unprivileged `uid=1000` user can trigger this if unprivileged\n user namespaces are enabled and it can create a userns+netns to obtain\n namespaced `CAP_NET_RAW` (the attached PoC does this).\n\n - Local denial of service: kernel BUG/panic (system crash).\n -\n---truncated---(CVE-2026-31415)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_log: account for netlink header size\n\nThis is a followup to an old bug fix: NLMSG_DONE needs to account\nfor the netlink header size, not just the attribute size.\n\nThis can result in a WARN splat + drop of the netlink message,\nbut other than this there are no ill effects.(CVE-2026-31416)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp\n\nprocess_sdp() declares union nf_inet_addr rtp_addr on the stack and\npasses it to the nf_nat_sip sdp_session hook after walking the SDP\nmedia descriptions. However rtp_addr is only initialized inside the\nmedia loop when a recognized media type with a non-zero port is found.\n\nIf the SDP body contains no m= lines, only inactive media sections\n(m=audio 0 ...) or only unrecognized media types, rtp_addr is never\nassigned. Despite that, the function still calls hooks->sdp_session()\nwith &rtp_addr, causing nf_nat_sdp_session() to format the stale stack\nvalue as an IP address and rewrite the SDP session owner and connection\nlines with it.\n\nWith CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this\nresults in the session-level o= and c= addresses being rewritten to\n0.0.0.0 for inactive SDP sessions. Without stack auto-init the\nrewritten address is whatever happened to be on the stack.\n\nFix this by pre-initializing rtp_addr from the session-level connection\naddress (caddr) when available, and tracking via a have_rtp_addr flag\nwhether any valid address was established. Skip the sdp_session hook\nentirely when no valid address exists.(CVE-2026-31427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD\n\n__build_packet_message() manually constructs the NFULA_PAYLOAD netlink\nattribute using skb_put() and skb_copy_bits(), bypassing the standard\nnla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes\nare allocated (including NLA alignment padding), only data_len bytes\nof actual packet data are copied. The trailing nla_padlen(data_len)\nbytes (1-3 when data_len is not 4-byte aligned) are never initialized,\nleaking stale heap contents to userspace via the NFLOG netlink socket.\n\nReplace the manual attribute construction with nla_reserve(), which\nhandles the tailroom check, header setup, and padding zeroing via\n__nla_reserve(). The subsequent skb_copy_bits() fills in the payload\ndata on top of the properly initialized attribute.(CVE-2026-31428)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\ncrypto: algif_aead - Revert to operating out-of-place\\n\\nThis mostly reverts commit 72548b093ee3 except for the copying of the associated data.\\n\\nThere is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.(CVE-2026-31431)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.0.7.134.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.0.7.134.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-devel-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-headers-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-source-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-tools-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-145.0.7.134.oe2403.aarch64.rpm","perf-6.6.0-145.0.7.134.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm","python3-perf-6.6.0-145.0.7.134.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-145.0.7.134.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-145.0.7.134.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-devel-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-headers-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-source-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-tools-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-145.0.7.134.oe2403.x86_64.rpm","perf-6.6.0-145.0.7.134.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm","python3-perf-6.6.0-145.0.7.134.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2176"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-27558"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71089"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23096"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23378"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23398"},{"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-23442"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23447"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23449"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23452"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23455"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23456"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23457"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23458"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23475"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31389"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31415"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31416"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31427"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31428"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31431"}],"database_specific":{"severity":"Critical"}}