{"schema_version":"1.7.2","id":"OESA-2026-1862","modified":"2026-04-11T14:04:16Z","published":"2026-04-11T14:04:16Z","upstream":["CVE-2025-68315","CVE-2025-68727","CVE-2026-23231","CVE-2026-23240","CVE-2026-23245","CVE-2026-23254","CVE-2026-23255","CVE-2026-23270","CVE-2026-23274","CVE-2026-23276","CVE-2026-23277","CVE-2026-23278","CVE-2026-23293","CVE-2026-23300","CVE-2026-23302","CVE-2026-23303","CVE-2026-23304","CVE-2026-23310","CVE-2026-23321","CVE-2026-23343","CVE-2026-23351","CVE-2026-23362","CVE-2026-23365","CVE-2026-23368","CVE-2026-23371","CVE-2026-23375","CVE-2026-23381","CVE-2026-23391","CVE-2026-23392","CVE-2026-23393","CVE-2026-23394","CVE-2026-23395","CVE-2026-23397","CVE-2026-23399","CVE-2026-23401","CVE-2026-23403","CVE-2026-23404","CVE-2026-23405","CVE-2026-23408","CVE-2026-23409","CVE-2026-23410","CVE-2026-23411","CVE-2026-23413","CVE-2026-23414","CVE-2026-31788"],"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\nf2fs: fix to detect potential corrupted nid in free_nid_list\n\nAs reported, on-disk footer.ino and footer.nid is the same and\nout-of-range, let's add sanity check on f2fs_alloc_nid() to detect\nany potential corruption in free_nid_list.(CVE-2025-68315)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: Fix uninit buffer allocated by __getname()\n\nFix uninit errors caused after buffer allocation given to 'de'; by\ninitializing the buffer with zeroes. The fix was found by using KMSAN.(CVE-2025-68727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix use-after-free in nf_tables_addchain()\n\nnf_tables_addchain() publishes the chain to table->chains via\nlist_add_tail_rcu() (in nft_chain_add()) before registering hooks.\nIf nf_tables_register_hook() then fails, the error path calls\nnft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy()\nwith no RCU grace period in between.\n\nThis creates two use-after-free conditions:\n\n 1) Control-plane: nf_tables_dump_chains() traverses table->chains\n    under rcu_read_lock(). A concurrent dump can still be walking\n    the chain when the error path frees it.\n\n 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly\n    installs the IPv4 hook before IPv6 registration fails.  Packets\n    entering nft_do_chain() via the transient IPv4 hook can still be\n    dereferencing chain->blob_gen_X when the error path frees the\n    chain.\n\nAdd synchronize_rcu() between nft_chain_del() and the chain destroy\nso that all RCU readers -- both dump threads and in-flight packet\nevaluation -- have finished before the chain is freed.(CVE-2026-23231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: Fix race condition in tls_sw_cancel_work_tx()\n\nThis issue was discovered during a code audit.\n\nAfter cancel_delayed_work_sync() is called from tls_sk_proto_close(),\ntx_work_handler() can still be scheduled from paths such as the\nDelayed ACK handler or ksoftirqd.\nAs a result, the tx_work_handler() worker may dereference a freed\nTLS object.\n\nThe following is a simple race scenario:\n\n          cpu0                         cpu1\n\ntls_sk_proto_close()\n  tls_sw_cancel_work_tx()\n                                 tls_write_space()\n                                   tls_sw_write_space()\n                                     if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask))\n    set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask);\n    cancel_delayed_work_sync(&ctx->tx_work.work);\n                                     schedule_delayed_work(&tx_ctx->tx_work.work, 0);\n\nTo prevent this race condition, cancel_delayed_work_sync() is\nreplaced with disable_delayed_work_sync().(CVE-2026-23240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_gate: snapshot parameters with RCU on replace\n\nThe gate action can be replaced while the hrtimer callback or dump path is\nwalking the schedule list.\n\nConvert the parameters to an RCU-protected snapshot and swap updates under\ntcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omits\nthe entry list, preserve the existing schedule so the effective state is\nunchanged.(CVE-2026-23245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gro: fix outer network offset\n\nThe udp GRO complete stage assumes that all the packets inserted the RX\nhave the `encapsulation` flag zeroed. Such assumption is not true, as a\nfew H/W NICs can set such flag when H/W offloading the checksum for\nan UDP encapsulated traffic, the tun driver can inject GSO packets with\nUDP encapsulation and the problematic layout can also be created via\na veth based setup.\n\nDue to the above, in the problematic scenarios, udp4_gro_complete() uses\nthe wrong network offset (inner instead of outer) to compute the outer\nUDP header pseudo checksum, leading to csum validation errors later on\nin packet processing.\n\nAddress the issue always clearing the encapsulation flag at GRO completion\ntime. Such flag will be set again as needed for encapsulated packets by\nudp_gro_complete().(CVE-2026-23254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: add proper RCU protection to /proc/net/ptype\n\nYin Fengwei reported an RCU stall in ptype_seq_show() and provided\na patch.\n\nReal issue is that ptype_seq_next() and ptype_seq_show() violate\nRCU rules.\n\nptype_seq_show() runs under rcu_read_lock(), and reads pt->dev\nto get device name without any barrier.\n\nAt the same time, concurrent writers can remove a packet_type structure\n(which is correctly freed after an RCU grace period) and clear pt->dev\nwithout an RCU grace period.\n\nDefine ptype_iter_state to carry a dev pointer along seq_net_private:\n\nstruct ptype_iter_state {\n\tstruct seq_net_private\tp;\n\tstruct net_device\t*dev; // added in this patch\n};\n\nWe need to record the device pointer in ptype_get_idx() and\nptype_seq_next() so that ptype_seq_show() is safe against\nconcurrent pt->dev changes.\n\nWe also need to add full RCU protection in ptype_seq_next().\n(Missing READ_ONCE() when reading list.next values)\n\nMany thanks to Dong Chenchen for providing a repro.(CVE-2026-23255)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks\n\nAs Paolo said earlier [1]:\n\n"Since the blamed commit below, classify can return TC_ACT_CONSUMED while\nthe current skb being held by the defragmentation engine. As reported by\nGangMin Kim, if such packet is that may cause a UaF when the defrag engine\nlater on tries to tuch again such packet."\n\nact_ct was never meant to be used in the egress path, however some users\nare attaching it to egress today [2]. Attempting to reach a middle\nground, we noticed that, while most qdiscs are not handling\nTC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we\naddress the issue by only allowing act_ct to bind to clsact/ingress\nqdiscs and shared blocks. That way it's still possible to attach act_ct to\negress (albeit only with clsact).\n\n[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/\n[2] https://lore.kernel.org/netdev/(CVE-2026-23270)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels\n\nIDLETIMER revision 0 rules reuse existing timers by label and always call\nmod_timer() on timer->timer.\n\nIf the label was created first by revision 1 with XT_IDLETIMER_ALARM,\nthe object uses alarm timer semantics and timer->timer is never initialized.\nReusing that object from revision 0 causes mod_timer() on an uninitialized\ntimer_list, triggering debugobjects warnings and possible panic when\npanic_on_warn=1.\n\nFix this by rejecting revision 0 rule insertion when an existing timer with\nthe same label is of ALARM type.(CVE-2026-23274)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: add xmit recursion limit to tunnel xmit functions\n\nTunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their own\nrecursion limit. When a bond device in broadcast mode has GRE tap\ninterfaces as slaves, and those GRE tunnels route back through the\nbond, multicast/broadcast traffic triggers infinite recursion between\nbond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causing\nkernel stack overflow.\n\nThe existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is not\nsufficient because tunnel recursion involves route lookups and full IP\noutput, consuming much more stack per level. Use a lower limit of 4\n(IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.\n\nAdd recursion detection using dev_xmit_recursion helpers directly in\niptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnel\npaths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).\n\nMove dev_xmit_recursion helpers from net/core/dev.h to public header\ninclude/linux/netdevice.h so they can be used by tunnel code.\n\n BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160\n Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11\n Workqueue: mld mld_ifc_work\n Call Trace:\n  <TASK>\n  __build_flow_key.constprop.0 (net/ipv4/route.c:515)\n  ip_rt_update_pmtu (net/ipv4/route.c:1073)\n  iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84)\n  ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)\n  gre_tap_xmit (net/ipv4/ip_gre.c:779)\n  dev_hard_start_xmit (net/core/dev.c:3887)\n  sch_direct_xmit (net/sched/sch_generic.c:347)\n  __dev_queue_xmit (net/core/dev.c:4802)\n  bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)\n  bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)\n  bond_start_xmit (drivers/net/bonding/bond_main.c:5530)\n  dev_hard_start_xmit (net/core/dev.c:3887)\n  __dev_queue_xmit (net/core/dev.c:4841)\n  ip_finish_output2 (net/ipv4/ip_output.c:237)\n  ip_output (net/ipv4/ip_output.c:438)\n  iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)\n  gre_tap_xmit (net/ipv4/ip_gre.c:779)\n  dev_hard_start_xmit (net/core/dev.c:3887)\n  sch_direct_xmit (net/sched/sch_generic.c:347)\n  __dev_queue_xmit (net/core/dev.c:4802)\n  bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)\n  bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)\n  bond_start_xmit (drivers/net/bonding/bond_main.c:5530)\n  dev_hard_start_xmit (net/core/dev.c:3887)\n  __dev_queue_xmit (net/core/dev.c:4841)\n  ip_finish_output2 (net/ipv4/ip_output.c:237)\n  ip_output (net/ipv4/ip_output.c:438)\n  iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)\n  ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)\n  gre_tap_xmit (net/ipv4/ip_gre.c:779)\n  dev_hard_start_xmit (net/core/dev.c:3887)\n  sch_direct_xmit (net/sched/sch_generic.c:347)\n  __dev_queue_xmit (net/core/dev.c:4802)\n  bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)\n  bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)\n  bond_start_xmit (drivers/net/bonding/bond_main.c:5530)\n  dev_hard_start_xmit (net/core/dev.c:3887)\n  __dev_queue_xmit (net/core/dev.c:4841)\n  mld_sendpack\n  mld_ifc_work\n  process_one_work\n  worker_thread\n  </TASK>(CVE-2026-23276)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit\n\nteql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit\nthrough slave devices, but does not update skb->dev to the slave device\nbeforehand.\n\nWhen a gretap tunnel is a TEQL slave, the transmit path reaches\niptunnel_xmit() which saves dev = skb->dev (still pointing to teql0\nmaster) and later calls iptunnel_xmit_stats(dev, pkt_len). This\nfunction does:\n\n    get_cpu_ptr(dev->tstats)\n\nSince teql_master_setup() does not set dev->pcpu_stat_type to\nNETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats\nfor teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes\nNULL + __per_cpu_offset[cpu], resulting in a page fault.\n\n BUG: unable to handle page fault for address: ffff8880e6659018\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 68bc067 P4D 68bc067 PUD 0\n Oops: Oops: 0002 [#1] SMP KASAN PTI\n RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89)\n Call Trace:\n  <TASK>\n  ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)\n  __gre_xmit (net/ipv4/ip_gre.c:478)\n  gre_tap_xmit (net/ipv4/ip_gre.c:779)\n  teql_master_xmit (net/sched/sch_teql.c:319)\n  dev_hard_start_xmit (net/core/dev.c:3887)\n  sch_direct_xmit (net/sched/sch_generic.c:347)\n  __dev_queue_xmit (net/core/dev.c:4802)\n  neigh_direct_output (net/core/neighbour.c:1660)\n  ip_finish_output2 (net/ipv4/ip_output.c:237)\n  __ip_finish_output.part.0 (net/ipv4/ip_output.c:315)\n  ip_mc_output (net/ipv4/ip_output.c:369)\n  ip_send_skb (net/ipv4/ip_output.c:1508)\n  udp_send_skb (net/ipv4/udp.c:1195)\n  udp_sendmsg (net/ipv4/udp.c:1485)\n  inet_sendmsg (net/ipv4/af_inet.c:859)\n  __sys_sendto (net/socket.c:2206)\n\nFix this by setting skb->dev = slave before calling\nnetdev_start_xmit(), so that tunnel xmit functions see the correct\nslave device with properly allocated tstats.(CVE-2026-23277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: always walk all pending catchall elements\n\nDuring transaction processing we might have more than one catchall element:\n1 live catchall element and 1 pending element that is coming as part of the\nnew batch.\n\nIf the map holding the catchall elements is also going away, its\nrequired to toggle all catchall elements and not just the first viable\ncandidate.\n\nOtherwise, we get:\n WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404\n RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables]\n [..]\n __nft_set_elem_destroy+0x106/0x380 [nf_tables]\n nf_tables_abort_release+0x348/0x8d0 [nf_tables]\n nf_tables_abort+0xcf2/0x3ac0 [nf_tables]\n nfnetlink_rcv_batch+0x9c9/0x20e0 [..](CVE-2026-23278)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled\n\nWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is never\ninitialized because inet6_init() exits before ndisc_init() is called\nwhich initializes it. If an IPv6 packet is injected into the interface,\nroute_shortcircuit() is called and a NULL pointer dereference happens on\nneigh_lookup().\n\n BUG: kernel NULL pointer dereference, address: 0000000000000380\n Oops: Oops: 0000 [#1] SMP NOPTI\n [...]\n RIP: 0010:neigh_lookup+0x20/0x270\n [...]\n Call Trace:\n  <TASK>\n  vxlan_xmit+0x638/0x1ef0 [vxlan]\n  dev_hard_start_xmit+0x9e/0x2e0\n  __dev_queue_xmit+0xbee/0x14e0\n  packet_sendmsg+0x116f/0x1930\n  __sys_sendto+0x1f5/0x200\n  __x64_sys_sendto+0x24/0x30\n  do_syscall_64+0x12f/0x1590\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFix this by adding an early check on route_shortcircuit() when protocol\nis ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because\nVXLAN can be built-in even when IPv6 is built as a module.(CVE-2026-23293)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop\n\nWhen a standalone IPv6 nexthop object is created with a loopback device\n(e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies\nit as a reject route. This is because nexthop objects have no destination\nprefix (fc_dst=::), causing fib6_is_reject() to match any loopback\nnexthop. The reject path skips fib_nh_common_init(), leaving\nnhc_pcpu_rth_output unallocated. If an IPv4 route later references this\nnexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and\npanics.\n\nSimplify the check in fib6_nh_init() to only match explicit reject\nroutes (RTF_REJECT) instead of using fib6_is_reject(). The loopback\npromotion heuristic in fib6_is_reject() is handled separately by\nip6_route_info_create_nh(). After this change, the three cases behave\nas follows:\n\n1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"):\n   RTF_REJECT is set, enters reject path, skips fib_nh_common_init().\n   No behavior change.\n\n2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"):\n   RTF_REJECT is not set, takes normal path, fib_nh_common_init() is\n   called. ip6_route_info_create_nh() still promotes it to reject\n   afterward. nhc_pcpu_rth_output is allocated but unused, which is\n   harmless.\n\n3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"):\n   RTF_REJECT is not set, takes normal path, fib_nh_common_init() is\n   called. nhc_pcpu_rth_output is properly allocated, fixing the crash\n   when IPv4 routes reference this nexthop.(CVE-2026-23300)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: annotate data-races around sk->sk_{data_ready,write_space}\n\nskmsg (and probably other layers) are changing these pointers\nwhile other cpus might read them concurrently.\n\nAdd corresponding READ_ONCE()/WRITE_ONCE() annotations\nfor UDP, TCP and AF_UNIX.(CVE-2026-23302)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Don't log plaintext credentials in cifs_set_cifscreds\n\nWhen debug logging is enabled, cifs_set_cifscreds() logs the key\npayload and exposes the plaintext username and password. Remove the\ndebug log to avoid exposing credentials.(CVE-2026-23303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()\n\nl3mdev_master_dev_rcu() can return NULL when the slave device is being\nun-slaved from a VRF. All other callers deal with this, but we lost\nthe fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu()\nwith commit 4832c30d5458 ("net: ipv6: put host and anycast routes on\ndevice with address").\n\n  KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]\n  RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)\n  Call Trace:\n   ip6_pol_route (net/ipv6/route.c:2318)\n   fib6_rule_lookup (net/ipv6/fib6_rules.c:115)\n   ip6_route_output_flags (net/ipv6/route.c:2607)\n   vrf_process_v6_outbound (drivers/net/vrf.c:437)\n\nI was tempted to rework the un-slaving code to clear the flag first\nand insert synchronize_rcu() before we remove the upper. But looks like\nthe explicit fallback to loopback_dev is an established pattern.\nAnd I guess avoiding the synchronize_rcu() is nice, too.(CVE-2026-23304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loaded\n\nbond_option_mode_set() already rejects mode changes that would make a\nloaded XDP program incompatible via bond_xdp_check().  However,\nbond_option_xmit_hash_policy_set() has no such guard.\n\nFor 802.3ad and balance-xor modes, bond_xdp_check() returns false when\nxmit_hash_policy is vlan+srcmac, because the 802.1q payload is usually\nabsent due to hardware offload.  This means a user can:\n\n1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode\n   with a compatible xmit_hash_policy (e.g. layer2+3).\n2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded.\n\nThis leaves bond->xdp_prog set but bond_xdp_check() now returning false\nfor the same device.  When the bond is later destroyed, dev_xdp_uninstall()\ncalls bond_xdp_set(dev, NULL, NULL) to remove the program, which hits\nthe bond_xdp_check() guard and returns -EOPNOTSUPP, triggering:\n\nWARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL))\n\nFix this by rejecting xmit_hash_policy changes to vlan+srcmac when an\nXDP program is loaded on a bond in 802.3ad or balance-xor mode.\n\ncommit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP")\nintroduced bond_xdp_check() which returns false for 802.3ad/balance-xor\nmodes when xmit_hash_policy is vlan+srcmac.  The check was wired into\nbond_xdp_set() to reject XDP attachment with an incompatible policy, but\nthe symmetric path -- preventing xmit_hash_policy from being changed to an\nincompatible value after XDP is already loaded -- was left unguarded in\nbond_option_xmit_hash_policy_set().\n\nNote:\ncommit 094ee6017ea0 ("bonding: check xdp prog when set bond mode")\nlater added a similar guard to bond_option_mode_set(), but\nbond_option_xmit_hash_policy_set() remained unprotected.(CVE-2026-23310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: in-kernel: always mark signal+subflow endp as used\n\nSyzkaller managed to find a combination of actions that was generating\nthis warning:\n\n  msk->pm.local_addr_used == 0\n  WARNING: net/mptcp/pm_kernel.c:1071 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline], CPU#1: syz.2.17/961\n  WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline], CPU#1: syz.2.17/961\n  WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full)\n  Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014\n  RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline]\n  RIP: 0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline]\n  RIP: 0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210\n  Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a\n  RSP: 0018:ffffc90001663880 EFLAGS: 00010293\n  RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500\n  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n  RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff\n  R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640\n  R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650\n  FS:  00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0\n  Call Trace:\n   <TASK>\n   genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115\n   genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n   genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210\n   netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550\n   genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n   netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]\n   netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344\n   netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894\n   sock_sendmsg_nosec net/socket.c:727 [inline]\n   __sock_sendmsg+0xc9/0xf0 net/socket.c:742\n   ____sys_sendmsg+0x272/0x3b0 net/socket.c:2592\n   ___sys_sendmsg+0x2de/0x320 net/socket.c:2646\n   __sys_sendmsg net/socket.c:2678 [inline]\n   __do_sys_sendmsg net/socket.c:2683 [inline]\n   __se_sys_sendmsg net/socket.c:2681 [inline]\n   __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681\n   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x7f66346f826d\n  Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\n  RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n  RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d\n  RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007\n  RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8\n  R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770\n   </TASK>\n\nThe actions that caused that seem to be:\n\n - Set the MPTCP subflows limit to 0\n - Create an MPTCP endpoint with both the 'signal' and 'subflow' flags\n - Create a new MPTCP connection from a different address: an ADD_ADDR\n   linked to the MPTCP endpoint will be sent ('signal' flag), but no\n   subflows is initiated ('subflow' flag)\n - Remove the MPTCP endpoint\n\n---truncated---(CVE-2026-23321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxdp: produce a warning when calculated tailroom is negative\n\nMany ethernet drivers report xdp Rx queue frag size as being the same as\nDMA write size. However, the only user of this field, namely\nbpf_xdp_frags_increase_tail(), clearly expects a truesize.\n\nSuch difference leads to unspecific memory corruption issues under certain\ncircumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when\nrunning xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses\nall DMA-writable space in 2 buffers. This would be fine, if only\nrxq->frag_size was properly set to 4K, but value of 3K results in a\nnegative tailroom, because there is a non-zero page offset.\n\nWe are supposed to return -EINVAL and be done with it in such case, but due\nto tailroom being stored as an unsigned int, it is reported to be somewhere\nnear UINT_MAX, resulting in a tail being grown, even if the requested\noffset is too much (it is around 2K in the abovementioned test). This later\nleads to all kinds of unspecific calltraces.\n\n[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6\n[ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4\n[ 7340.338179]  in libc.so.6[61c9d,7f4161aaf000+160000]\n[ 7340.339230]  in xskxceiver[42b5,400000+69000]\n[ 7340.340300]  likely on CPU 6 (core 0, socket 6)\n[ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe\n[ 7340.340888]  likely on CPU 3 (core 0, socket 3)\n[ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7\n[ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI\n[ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy)\n[ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014\n[ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80\n[ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89\n[ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202\n[ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010\n[ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff\n[ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0\n[ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0\n[ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500\n[ 7340.418229] FS:  0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000\n[ 7340.419489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0\n[ 7340.421237] PKRU: 55555554\n[ 7340.421623] Call Trace:\n[ 7340.421987]  <TASK>\n[ 7340.422309]  ? softleaf_from_pte+0x77/0xa0\n[ 7340.422855]  swap_pte_batch+0xa7/0x290\n[ 7340.423363]  zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270\n[ 7340.424102]  zap_pte_range+0x281/0x580\n[ 7340.424607]  zap_pmd_range.isra.0+0xc9/0x240\n[ 7340.425177]  unmap_page_range+0x24d/0x420\n[ 7340.425714]  unmap_vmas+0xa1/0x180\n[ 7340.426185]  exit_mmap+0xe1/0x3b0\n[ 7340.426644]  __mmput+0x41/0x150\n[ 7340.427098]  exit_mm+0xb1/0x110\n[ 7340.427539]  do_exit+0x1b2/0x460\n[ 7340.427992]  do_group_exit+0x2d/0xc0\n[ 7340.428477]  get_signal+0x79d/0x7e0\n[ 7340.428957]  arch_do_signal_or_restart+0x34/0x100\n[ 7340.429571]  exit_to_user_mode_loop+0x8e/0x4c0\n[ 7340.430159]  do_syscall_64+0x188/\n---truncated---(CVE-2026-23343)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: split gc into unlink and reclaim phase\n\nYiming Qian reports Use-after-free in the pipapo set type:\n  Under a large number of expired elements, commit-time GC can run for a very\n  long time in a non-preemptible context, triggering soft lockup warnings and\n  RCU stall reports (local denial of service).\n\nWe must split GC in an unlink and a reclaim phase.\n\nWe cannot queue elements for freeing until pointers have been swapped.\nExpired elements are still exposed to both the packet path and userspace\ndumpers via the live copy of the data structure.\n\ncall_rcu() does not protect us: dump operations or element lookups starting\nafter call_rcu has fired can still observe the free'd element, unless the\ncommit phase has made enough progress to swap the clone and live pointers\nbefore any new reader has picked up the old version.\n\nThis a similar approach as done recently for the rbtree backend in commit\n35f83a75529a ("netfilter: nft_set_rbtree: don't gc elements on insert").(CVE-2026-23351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: fix locking for bcm_op runtime updates\n\nCommit c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates")\nadded a locking for some variables that can be modified at runtime when\nupdating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup().\n\nUsually the RX_SETUP only handles and filters incoming traffic with one\nexception: When the RX_RTR_FRAME flag is set a predefined CAN frame is\nsent when a specific RTR frame is received. Therefore the rx bcm_op uses\nbcm_can_tx() which uses the bcm_tx_lock that was only initialized in\nbcm_tx_setup(). Add the missing spin_lock_init() when allocating the\nbcm_op in bcm_rx_setup() to handle the RTR case properly.(CVE-2026-23362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: kalmia: validate USB endpoints\n\nThe kalmia driver should validate that the device it is probing has the\nproper number and types of USB endpoints it is expecting before it binds\nto it.  If a malicious device were to not have the same urbs the driver\nwill crash later on when it blindly accesses these endpoints.(CVE-2026-23365)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: register phy led_triggers during probe to avoid AB-BA deadlock\n\nThere is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and\nLED_TRIGGER_PHY are enabled:\n\n[ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc             <-- Trying to get lock "triggers_list_lock" via down_write(&triggers_list_lock);\n[ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234\n[ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c\n[ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c\n[ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0\n[ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0\n[ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c\n[ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78\n[ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654                       <-- Hold lock "rtnl_mutex" by calling rtnl_lock();\n[ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0\n[ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c\n[ 1362.104022] [<80014504>] syscall_common+0x34/0x58\n\nHere LED_TRIGGER_PHY is registering LED triggers during phy_attach\nwhile holding RTNL and then taking triggers_list_lock.\n\n[ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168      <-- Trying to get lock "rtnl_mutex" via rtnl_lock();\n[ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4\n[ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360                 <-- Hold lock "triggers_list_lock" by down_read(&triggers_list_lock);\n[ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c\n[ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc\n[ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c\n[ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4\n[ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c\n[ 1362.232164] [<80014504>] syscall_common+0x34/0x58\n\nHere LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes\ntriggers_list_lock and then RTNL. A classical AB-BA deadlock.\n\nphy_led_triggers_registers() does not require the RTNL, it does not\nmake any calls into the network stack which require protection. There\nis also no requirement the PHY has been attached to a MAC, the\ntriggers only make use of phydev state. This allows the call to\nphy_led_triggers_registers() to be placed elsewhere. PHY probe() and\nrelease() don't hold RTNL, so solving the AB-BA deadlock.(CVE-2026-23368)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting\n\nRunning stress-ng --schedpolicy 0 on an RT kernel on a big machine\nmight lead to the following WARNINGs (edited).\n\n sched: DL de-boosted task PID 22725: REPLENISH flag missing\n\n WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8\n ... (running_bw underflow)\n Call trace:\n  dequeue_task_dl+0x15c/0x1f8 (P)\n  dequeue_task+0x80/0x168\n  deactivate_task+0x24/0x50\n  push_dl_task+0x264/0x2e0\n  dl_task_timer+0x1b0/0x228\n  __hrtimer_run_queues+0x188/0x378\n  hrtimer_interrupt+0xfc/0x260\n  ...\n\nThe problem is that when a SCHED_DEADLINE task (lock holder) is\nchanged to a lower priority class via sched_setscheduler(), it may\nfail to properly inherit the parameters of potential DEADLINE donors\nif it didn't already inherit them in the past (shorter deadline than\ndonor's at that time). This might lead to bandwidth accounting\ncorruption, as enqueue_task_dl() won't recognize the lock holder as\nboosted.\n\nThe scenario occurs when:\n1. A DEADLINE task (donor) blocks on a PI mutex held by another\n   DEADLINE task (holder), but the holder doesn't inherit parameters\n   (e.g., it already has a shorter deadline)\n2. sched_setscheduler() changes the holder from DEADLINE to a lower\n   class while still holding the mutex\n3. The holder should now inherit DEADLINE parameters from the donor\n   and be enqueued with ENQUEUE_REPLENISH, but this doesn't happen\n\nFix the issue by introducing __setscheduler_dl_pi(), which detects when\na DEADLINE (proper or boosted) task gets setscheduled to a lower\npriority class. In case, the function makes the task inherit DEADLINE\nparameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to\nensure proper bandwidth accounting during the next enqueue operation.(CVE-2026-23371)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: thp: deny THP for files on anonymous inodes\n\nfile_thp_enabled() incorrectly allows THP for files on anonymous inodes\n(e.g. guest_memfd and secretmem). These files are created via\nalloc_file_pseudo(), which does not call get_write_access() and leaves\ninode->i_writecount at 0. Combined with S_ISREG(inode->i_mode) being\ntrue, they appear as read-only regular files when\nCONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP\ncollapse.\n\nAnonymous inodes can never pass the inode_is_open_for_write() check\nsince their i_writecount is never incremented through the normal VFS\nopen path. The right thing to do is to exclude them from THP eligibility\naltogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real\nfilesystem files (e.g. shared libraries), not for pseudo-filesystem\ninodes.\n\nFor guest_memfd, this allows khugepaged and MADV_COLLAPSE to create\nlarge folios in the page cache via the collapse path, but the\nguest_memfd fault handler does not support large folios. This triggers\nWARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().\n\nFor secretmem, collapse_file() tries to copy page contents through the\ndirect map, but secretmem pages are removed from the direct map. This\ncan result in a kernel crash:\n\n    BUG: unable to handle page fault for address: ffff88810284d000\n    RIP: 0010:memcpy_orig+0x16/0x130\n    Call Trace:\n     collapse_file\n     hpage_collapse_scan_file\n     madvise_collapse\n\nSecretmem is not affected by the crash on upstream as the memory failure\nrecovery handles the failed copy gracefully, but it still triggers\nconfusing false memory failure reports:\n\n    Memory failure: 0x106d96f: recovery action for clean unevictable\n    LRU page: Recovered\n\nCheck IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all\nanonymous inode files.(CVE-2026-23375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix nd_tbl NULL dereference when IPv6 is disabled\n\nWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is never\ninitialized because inet6_init() exits before ndisc_init() is called\nwhich initializes it. Then, if neigh_suppress is enabled and an ICMPv6\nNeighbor Discovery packet reaches the bridge, br_do_suppress_nd() will\ndereference ipv6_stub->nd_tbl which is NULL, passing it to\nneigh_lookup(). This causes a kernel NULL pointer dereference.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000268\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n [...]\n RIP: 0010:neigh_lookup+0x16/0xe0\n [...]\n Call Trace:\n  <IRQ>\n  ? neigh_lookup+0x16/0xe0\n  br_do_suppress_nd+0x160/0x290 [bridge]\n  br_handle_frame_finish+0x500/0x620 [bridge]\n  br_handle_frame+0x353/0x440 [bridge]\n  __netif_receive_skb_core.constprop.0+0x298/0x1110\n  __netif_receive_skb_one_core+0x3d/0xa0\n  process_backlog+0xa0/0x140\n  __napi_poll+0x2c/0x170\n  net_rx_action+0x2c4/0x3a0\n  handle_softirqs+0xd0/0x270\n  do_softirq+0x3f/0x60\n\nFix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in\nthe callers. This is in essence disabling NS/NA suppression when IPv6 is\ndisabled.(CVE-2026-23381)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_CT: drop pending enqueued packets on template removal\n\nTemplates refer to objects that can go away while packets are sitting in\nnfqueue refer to:\n\n- helper, this can be an issue on module removal.\n- timeout policy, nfnetlink_cttimeout might remove it.\n\nThe use of templates with zone and event cache filter are safe, since\nthis just copies values.\n\nFlush these enqueued packets in case the template rule gets removed.(CVE-2026-23391)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: release flowtable after rcu grace period on error\n\nCall synchronize_rcu() after unregistering the hooks from error path,\nsince a hook that already refers to this flowtable can be already\nregistered, exposing this flowtable to packet path and nfnetlink_hook\ncontrol plane.\n\nThis error path is rare, it should only happen by reaching the maximum\nnumber hooks or by failing to set up to hardware offload, just call\nsynchronize_rcu().\n\nThere is a check for already used device hooks by different flowtable\nthat could result in EEXIST at this late stage. The hook parser can be\nupdated to perform this check earlier to this error path really becomes\nrarely exercised.\n\nUncovered by KASAN reported as use-after-free from nfnetlink_hook path\nwhen dumping hooks.(CVE-2026-23392)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: cfm: Fix race condition in peer_mep deletion\n\nWhen a peer MEP is being deleted, cancel_delayed_work_sync() is called\non ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in\nsoftirq context under rcu_read_lock (without RTNL) and can re-schedule\nccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()\nreturning and kfree_rcu() being called.\n\nThe following is a simple race scenario:\n\n           cpu0                                     cpu1\n\nmep_delete_implementation()\n  cancel_delayed_work_sync(ccm_rx_dwork);\n                                           br_cfm_frame_rx()\n                                             // peer_mep still in hlist\n                                             if (peer_mep->ccm_defect)\n                                               ccm_rx_timer_start()\n                                                 queue_delayed_work(ccm_rx_dwork)\n  hlist_del_rcu(&peer_mep->head);\n  kfree_rcu(peer_mep, rcu);\n                                           ccm_rx_work_expired()\n                                             // on freed peer_mep\n\nTo prevent this, cancel_delayed_work_sync() is replaced with\ndisable_delayed_work_sync() in both peer MEP deletion paths, so\nthat subsequent queue_delayed_work() calls from br_cfm_frame_rx()\nare silently rejected.\n\nThe cc_peer_disable() helper retains cancel_delayed_work_sync()\nbecause it is also used for the CC enable/disable toggle path where\nthe work must remain re-schedulable.(CVE-2026-23393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Give up GC if MSG_PEEK intervened.\n\nIgor Ushakov reported that GC purged the receive queue of\nan alive socket due to a race with MSG_PEEK with a nice repro.\n\nThis is the exact same issue previously fixed by commit\ncbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").\n\nAfter GC was replaced with the current algorithm, the cited\ncommit removed the locking dance in unix_peek_fds() and\nreintroduced the same issue.\n\nThe problem is that MSG_PEEK bumps a file refcount without\ninteracting with GC.\n\nConsider an SCC containing sk-A and sk-B, where sk-A is\nclose()d but can be recv()ed via sk-B.\n\nThe bad thing happens if sk-A is recv()ed with MSG_PEEK from\nsk-B and sk-B is close()d while GC is checking unix_vertex_dead()\nfor sk-A and sk-B.\n\n  GC thread                    User thread\n  ---------                    -----------\n  unix_vertex_dead(sk-A)\n  -> true   <------.\n                    \\\n                     `------   recv(sk-B, MSG_PEEK)\n              invalidate !!    -> sk-A's file refcount : 1 -> 2\n\n                               close(sk-B)\n                               -> sk-B's file refcount : 2 -> 1\n  unix_vertex_dead(sk-B)\n  -> true\n\nInitially, sk-A's file refcount is 1 by the inflight fd in sk-B\nrecvq.  GC thinks sk-A is dead because the file refcount is the\nsame as the number of its inflight fds.\n\nHowever, sk-A's file refcount is bumped silently by MSG_PEEK,\nwhich invalidates the previous evaluation.\n\nAt this moment, sk-B's file refcount is 2; one by the open fd,\nand one by the inflight fd in sk-A.  The subsequent close()\nreleases one refcount by the former.\n\nFinally, GC incorrectly concludes that both sk-A and sk-B are dead.\n\nOne option is to restore the locking dance in unix_peek_fds(),\nbut we can resolve this more elegantly thanks to the new algorithm.\n\nThe point is that the issue does not occur without the subsequent\nclose() and we actually do not need to synchronise MSG_PEEK with\nthe dead SCC detection.\n\nWhen the issue occurs, close() and GC touch the same file refcount.\nIf GC sees the refcount being decremented by close(), it can just\ngive up garbage-collecting the SCC.\n\nTherefore, we only need to signal the race during MSG_PEEK with\na proper memory barrier to make it visible to the GC.\n\nLet's use seqcount_t to notify GC when MSG_PEEK occurs and let\nit defer the SCC to the next run.\n\nThis way no locking is needed on the MSG_PEEK side, and we can\navoid imposing a penalty on every MSG_PEEK unnecessarily.\n\nNote that we can retry within unix_scc_dead() if MSG_PEEK is\ndetected, but we do not do so to avoid hung task splat from\nabusive MSG_PEEK calls.(CVE-2026-23394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ\n\nCurrently the code attempts to accept requests regardless of the\ncommand identifier which may cause multiple requests to be marked\nas pending (FLAG_DEFER_SETUP) which can cause more than\nL2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer\ncausing an overflow.\n\nThe spec is quite clear that the same identifier shall not be used on\nsubsequent requests:\n\n'Within each signaling channel a different Identifier shall be used\nfor each successive request or indication.'\nhttps://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d\n\nSo this attempts to check if there are any channels pending with the\nsame identifier and rejects if any are found.(CVE-2026-23395)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfnetlink_osf: validate individual option lengths in fingerprints\n\nnfnl_osf_add_callback() validates opt_num bounds and string\nNUL-termination but does not check individual option length fields.\nA zero-length option causes nf_osf_match_one() to enter the option\nmatching loop even when foptsize sums to zero, which matches packets\nwith no TCP options where ctx->optp is NULL:\n\n Oops: general protection fault\n KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98)\n Call Trace:\n  nf_osf_match (net/netfilter/nfnetlink_osf.c:227)\n  xt_osf_match_packet (net/netfilter/xt_osf.c:32)\n  ipt_do_table (net/ipv4/netfilter/ip_tables.c:293)\n  nf_hook_slow (net/netfilter/core.c:623)\n  ip_local_deliver (net/ipv4/ip_input.c:262)\n  ip_rcv (net/ipv4/ip_input.c:573)\n\nAdditionally, an MSS option (kind=2) with length < 4 causes\nout-of-bounds reads when nf_osf_match_one() unconditionally accesses\noptp[2] and optp[3] for MSS value extraction.  While RFC 9293\nsection 3.2 specifies that the MSS option is always exactly 4\nbytes (Kind=2, Length=4), the check uses "< 4" rather than\n"!= 4" because lengths greater than 4 do not cause memory\nsafety issues -- the buffer is guaranteed to be at least\nfoptsize bytes by the ctx->optsize == foptsize check.\n\nReject fingerprints where any option has zero length, or where an MSS\noption has length less than 4, at add time rather than trusting these\nvalues in the packet matching hot path.(CVE-2026-23397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnf_tables: nft_dynset: fix possible stateful expression memleak in error path\n\nIf cloning the second stateful expression in the element via GFP_ATOMIC\nfails, then the first stateful expression remains in place without being\nreleased.\n\n   unreferenced object (percpu) 0x607b97e9cab8 (size 16):\n     comm "softirq", pid 0, jiffies 4294931867\n     hex dump (first 16 bytes on cpu 3):\n       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n     backtrace (crc 0):\n       pcpu_alloc_noprof+0x453/0xd80\n       nft_counter_clone+0x9c/0x190 [nf_tables]\n       nft_expr_clone+0x8f/0x1b0 [nf_tables]\n       nft_dynset_new+0x2cb/0x5f0 [nf_tables]\n       nft_rhash_update+0x236/0x11c0 [nf_tables]\n       nft_dynset_eval+0x11f/0x670 [nf_tables]\n       nft_do_chain+0x253/0x1700 [nf_tables]\n       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]\n       nf_hook_slow+0xaa/0x1e0\n       ip_local_deliver+0x209/0x330(CVE-2026-23399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\n\nWhen installing an emulated MMIO SPTE, do so *after* dropping/zapping the\nexisting SPTE (if it's shadow-present).  While commit a54aa15c6bda3 was\nright about it being impossible to convert a shadow-present SPTE to an\nMMIO SPTE due to a _guest_ write, it failed to account for writes to guest\nmemory that are outside the scope of KVM.\n\nE.g. if host userspace modifies a shadowed gPTE to switch from a memslot\nto emulted MMIO and then the guest hits a relevant page fault, KVM will\ninstall the MMIO SPTE without first zapping the shadow-present SPTE.\n\n  ------------[ cut here ]------------\n  is_shadow_present_pte(*sptep)\n  WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292\n  Modules linked in: kvm_intel kvm irqbypass\n  CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm]\n  Call Trace:\n   <TASK>\n   mmu_set_spte+0x237/0x440 [kvm]\n   ept_page_fault+0x535/0x7f0 [kvm]\n   kvm_mmu_do_page_fault+0xee/0x1f0 [kvm]\n   kvm_mmu_page_fault+0x8d/0x620 [kvm]\n   vmx_handle_exit+0x18c/0x5a0 [kvm_intel]\n   kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm]\n   kvm_vcpu_ioctl+0x2d5/0x980 [kvm]\n   __x64_sys_ioctl+0x8a/0xd0\n   do_syscall_64+0xb5/0x730\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  RIP: 0033:0x47fa3f\n   </TASK>\n  ---[ end trace 0000000000000000 ]---(CVE-2026-23401)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix memory leak in verify_header\n\nThe function sets `*ns = NULL` on every call, leaking the namespace\nstring allocated in previous iterations when multiple profiles are\nunpacked. This also breaks namespace consistency checking since *ns\nis always NULL when the comparison is made.\n\nRemove the incorrect assignment.\nThe caller (aa_unpack) initializes *ns to NULL once before the loop,\nwhich is sufficient.(CVE-2026-23403)\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\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\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix differential encoding verification\n\nDifferential encoding allows loops to be created if it is abused. To\nprevent this the unpack should verify that a diff-encode chain\nterminates.\n\nUnfortunately the differential encode verification had two bugs.\n\n1. it conflated states that had gone through check and already been\n   marked, with states that were currently being checked and marked.\n   This means that loops in the current chain being verified are treated\n   as a chain that has already been verified.\n\n2. the order bailout on already checked states compared current chain\n   check iterators j,k instead of using the outer loop iterator i.\n   Meaning a step backwards in states in the current chain verification\n   was being mistaken for moving to an already verified state.\n\nMove to a double mark scheme where already verified states get a\ndifferent mark, than the current chain being kept. This enables us\nto also drop the backwards verification check that was the cause of\nthe second error as any already verified state is already marked.(CVE-2026-23409)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix race on rawdata dereference\n\nThere is a race condition that leads to a use-after-free situation:\nbecause the rawdata inodes are not refcounted, an attacker can start\nopen()ing one of the rawdata files, and at the same time remove the\nlast reference to this rawdata (by removing the corresponding profile,\nfor example), which frees its struct aa_loaddata; as a result, when\nseq_rawdata_open() is reached, i_private is a dangling pointer and\nfreed memory is accessed.\n\nThe rawdata inodes weren't refcounted to avoid a circular refcount and\nwere supposed to be held by the profile rawdata reference.  However\nduring profile removal there is a window where the vfs and profile\ndestruction race, resulting in the use after free.\n\nFix this by moving to a double refcount scheme. Where the profile\nrefcount on rawdata is used to break the circular dependency. Allowing\nfor freeing of the rawdata once all inode references to the rawdata\nare put.(CVE-2026-23410)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix race between freeing data and fs accessing it\n\nAppArmor was putting the reference to i_private data on its end after\nremoving the original entry from the file system. However the inode\ncan aand does live beyond that point and it is possible that some of\nthe fs call back functions will be invoked after the reference has\nbeen put, which results in a race between freeing the data and\naccessing it through the fs.\n\nWhile the rawdata/loaddata is the most likely candidate to fail the\nrace, as it has the fewest references. If properly crafted it might be\npossible to trigger a race for the other types stored in i_private.\n\nFix this by moving the put of i_private referenced data to the correct\nplace which is during inode eviction.(CVE-2026-23411)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclsact: Fix use-after-free in init/destroy rollback asymmetry\n\nFix a use-after-free in the clsact qdisc upon init/destroy rollback asymmetry.\nThe latter is achieved by first fully initializing a clsact instance, and\nthen in a second step having a replacement failure for the new clsact qdisc\ninstance. clsact_init() initializes ingress first and then takes care of the\negress part. This can fail midway, for example, via tcf_block_get_ext(). Upon\nfailure, the kernel will trigger the clsact_destroy() callback.\n\nCommit 1cb6f0bae504 ("bpf: Fix too early release of tcx_entry") details the\nway how the transition is happening. If tcf_block_get_ext on the q->ingress_block\nends up failing, we took the tcx_miniq_inc reference count on the ingress\nside, but not yet on the egress side. clsact_destroy() tests whether the\n{ingress,egress}_entry was non-NULL. However, even in midway failure on the\nreplacement, both are in fact non-NULL with a valid egress_entry from the\nprevious clsact instance.\n\nWhat we really need to test for is whether the qdisc instance-specific ingress\nor egress side previously got initialized. This adds a small helper for checking\nthe miniq initialization called mini_qdisc_pair_inited, and utilizes that upon\nclsact_destroy() in order to fix the use-after-free scenario. Convert the\ningress_destroy() side as well so both are consistent to each other.(CVE-2026-23413)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: Purge async_hold in tls_decrypt_async_wait()\n\nThe async_hold queue pins encrypted input skbs while\nthe AEAD engine references their scatterlist data. Once\ntls_decrypt_async_wait() returns, every AEAD operation\nhas completed and the engine no longer references those\nskbs, so they can be freed unconditionally.\n\nA subsequent patch adds batch async decryption to\ntls_sw_read_sock(), introducing a new call site that\nmust drain pending AEAD operations and release held\nskbs. Move __skb_queue_purge(&ctx->async_hold) into\ntls_decrypt_async_wait() so the purge is centralized\nand every caller -- recvmsg's drain path, the -EBUSY\nfallback in tls_do_decryption(), and the new read_sock\nbatch path -- releases held skbs on synchronization\nwithout each site managing the purge independently.\n\nThis fixes a leak when tls_strp_msg_hold() fails part-way through,\nafter having added some cloned skbs to the async_hold\nqueue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to\nprocess all pending decrypts, and drop back to synchronous mode, but\ntls_sw_recvmsg() only flushes the async_hold queue when one record has\nbeen processed in "fully-async" mode, which may not be the case here.\n\n[(CVE-2026-23414)\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)","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.2.130.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.0.2.130.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-devel-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-headers-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-source-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-tools-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.0.2.130.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-145.0.2.130.oe2403.aarch64.rpm","perf-6.6.0-145.0.2.130.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-145.0.2.130.oe2403.aarch64.rpm","python3-perf-6.6.0-145.0.2.130.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.0.2.130.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-145.0.2.130.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-145.0.2.130.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-devel-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-headers-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-source-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-tools-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.0.2.130.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-145.0.2.130.oe2403.x86_64.rpm","perf-6.6.0-145.0.2.130.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-145.0.2.130.oe2403.x86_64.rpm","python3-perf-6.6.0-145.0.2.130.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.0.2.130.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1862"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68315"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68727"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23231"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23240"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23245"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23254"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23255"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23270"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23274"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23276"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23277"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23278"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23293"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23300"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23302"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23303"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23304"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23310"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23321"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23343"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23351"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23362"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23365"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23368"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23371"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23375"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23381"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23391"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23392"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23393"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23394"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23395"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23397"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23399"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23401"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23403"},{"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-23408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23409"},{"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-23413"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23414"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31788"}],"database_specific":{"severity":"Critical"}}