{"schema_version":"1.7.2","id":"OESA-2026-2173","modified":"2026-05-03T09:57:19Z","published":"2026-05-03T09:57:19Z","upstream":["CVE-2026-23398","CVE-2026-23447","CVE-2026-23449","CVE-2026-23455","CVE-2026-23456","CVE-2026-23457","CVE-2026-23458","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\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\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\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 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-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.0.7.138.oe2403sp3"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","bpftool-debuginfo-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-debuginfo-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-debugsource-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-devel-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-extra-modules-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-headers-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-source-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-tools-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","kernel-tools-devel-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","perf-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","perf-debuginfo-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","python3-perf-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.0.7.138.oe2403sp3.aarch64.rpm"],"src":["kernel-6.6.0-145.0.7.138.oe2403sp3.src.rpm"],"x86_64":["bpftool-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","bpftool-debuginfo-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-debuginfo-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-debugsource-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-devel-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-extra-modules-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-headers-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-source-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-tools-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","kernel-tools-devel-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","perf-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","perf-debuginfo-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","python3-perf-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.0.7.138.oe2403sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2173"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23398"},{"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-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-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"}}