OESA-2026-2173 (CVE-2026-23398)

Vulnerability from osv_openeuler – Published: 2026-05-03 11:11 – Updated: 2026-08-06 11:11 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

icmp: fix NULL pointer dereference in icmp_tag_validation()

icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context.

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: <IRQ> icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) </IRQ>

Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.(CVE-2026-23398)

In the Linux kernel, the following vulnerability has been resolved:

net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check

The same bounds-check bug fixed for NDP16 in the previous patch also exists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated against the total skb length without accounting for ndpoffset, allowing out-of-bounds reads when the NDP32 is placed near the end of the NTB.

Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly.

Compile-tested only.(CVE-2026-23447)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: teql: Fix double-free in teql_master_xmit

Whenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should be called using the seq_lock to avoid racing with the datapath. Failure to do so may cause crashes like the following:

[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139) [ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318 [ 238.029749][ T318] [ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full) [ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 238.029910][ T318] Call Trace: [ 238.029913][ T318] <TASK> [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122) [ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563) [ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231) [ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1)) [ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139) ... [ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256) [ 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) [ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034) [ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157) [ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077) [ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091) [ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556) ... [ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s: [ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369) [ 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) [ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107)) [ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713) [ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763) [ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997) [ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108) [ 238.081469][ T318] [ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s: [ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1)) [ 238.085900][ T318] __kasan_slab_free (mm/ ---truncated---(CVE-2026-23449)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()

In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read.

Add a check to ensure len is positive after the decrement.(CVE-2026-23455)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case

In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read.

Add a boundary check for len bytes after get_bits() and before get_uint().(CVE-2026-23456)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()

sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary.

For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser.

Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.(CVE-2026-23457)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()

ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext.

The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose.

Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily.

BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133

CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: <TASK> ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0

Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180

Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0(CVE-2026-23458)

In the Linux kernel, the following vulnerability has been resolved:

spi: fix use-after-free on controller registration failure

Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses.(CVE-2026-31389)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: avoid overflows in ip6_datagram_send_ctl()

Yiming Qian reported : <quote> I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via skb_under_panic() (local DoS).

The core issue is a mismatch between:

  • a 16-bit length accumulator (struct ipv6_txoptions::opt_flen, type __u16) and
  • a pointer to the last provided destination-options header (opt-&gt;dst1opt)

when multiple IPV6_DSTOPTS control messages (cmsgs) are provided.

  • include/net/ipv6.h:
  • struct ipv6_txoptions::opt_flen is __u16 (wrap possible). (lines 291-307, especially 298)
  • net/ipv6/datagram.c:ip6_datagram_send_ctl():
  • Accepts repeated IPV6_DSTOPTS and accumulates into opt_flen without rejecting duplicates. (lines 909-933)
  • net/ipv6/ip6_output.c:__ip6_append_data():
  • Uses opt-&gt;opt_flen + opt-&gt;opt_nflen to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465)
  • net/ipv6/ip6_output.c:__ip6_make_skb():
  • Calls ipv6_push_frag_opts() if opt-&gt;opt_flen is non-zero. (lines 1930-1934)
  • net/ipv6/exthdrs.c:ipv6_push_frag_opts() / ipv6_push_exthdr():

  • Push size comes from ipv6_optlen(opt-&gt;dst1opt) (based on the pointed-to header). (lines 1179-1185 and 1206-1211)

  • opt_flen is a 16-bit accumulator:

  • include/net/ipv6.h:298 defines __u16 opt_flen; /* after fragment hdr */.

  • ip6_datagram_send_ctl() accepts repeated IPV6_DSTOPTS cmsgs and increments opt_flen each time:

  • In net/ipv6/datagram.c:909-933, for IPV6_DSTOPTS:

  • It computes len = ((hdr-&gt;hdrlen + 1) &lt;&lt; 3);
  • It checks CAP_NET_RAW using ns_capable(net-&gt;user_ns, CAP_NET_RAW). (line 922)
  • Then it does:
    • opt-&gt;opt_flen += len; (line 927)
    • opt-&gt;dst1opt = hdr; (line 928)

There is no duplicate rejection here (unlike the legacy IPV6_2292DSTOPTS path which rejects duplicates at net/ipv6/datagram.c:901-904).

If enough large IPV6_DSTOPTS cmsgs are provided, opt_flen wraps while dst1opt still points to a large (2048-byte) destination-options header.

In the attached PoC (poc.c):

  • 32 cmsgs with hdrlen=255 => len = (255+1)*8 = 2048
  • 1 cmsg with hdrlen=0 => len = 8
  • Total increment: 32*2048 + 8 = 65544, so (__u16)opt_flen == 8

  • The last cmsg is 2048 bytes, so dst1opt points to a 2048-byte header.

  • The transmit path sizes headers using the wrapped opt_flen:

  • In net/ipv6/ip6_output.c:1463-1465:

  • headersize = sizeof(struct ipv6hdr) + (opt ? opt-&gt;opt_flen + opt-&gt;opt_nflen : 0) + ...;

With wrapped opt_flen, headersize/headroom decisions underestimate what will be pushed later.

  1. When building the final skb, the actual push length comes from dst1opt and is not limited by wrapped opt_flen:

  2. In net/ipv6/ip6_output.c:1930-1934:

  3. if (opt-&gt;opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);
  4. In net/ipv6/exthdrs.c:1206-1211, ipv6_push_frag_opts() pushes dst1opt via ipv6_push_exthdr().
  5. In net/ipv6/exthdrs.c:1179-1184, ipv6_push_exthdr() does:
  6. skb_push(skb, ipv6_optlen(opt));
  7. memcpy(h, opt, ipv6_optlen(opt));

With insufficient headroom, skb_push() underflows and triggers skb_under_panic() -> BUG():

  • net/core/skbuff.c:2669-2675 (skb_push() calls skb_under_panic())

  • net/core/skbuff.c:207-214 (skb_panic() ends in BUG())

  • The IPV6_DSTOPTS cmsg path requires CAP_NET_RAW in the target netns user namespace (ns_capable(net-&gt;user_ns, CAP_NET_RAW)).

  • Root (or any task with CAP_NET_RAW) can trigger this without user namespaces.

  • An unprivileged uid=1000 user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced CAP_NET_RAW (the attached PoC does this).

  • Local denial of service: kernel BUG/panic (system crash). - ---truncated---(CVE-2026-31415)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlink_log: account for netlink header size

This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size.

This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.(CVE-2026-31416)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp

process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found.

If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it.

With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack.

Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.(CVE-2026-31427)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD

__build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket.

Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.(CVE-2026-31428)

In 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)

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.0.7.138.oe2403sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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  \u0026lt;IRQ\u0026gt;\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  \u0026lt;/IRQ\u0026gt;\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]  \u0026lt;TASK\u0026gt;\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-\u0026gt;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-\u0026gt;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-\u0026gt;args[0] early-return check in the dump\ncallback to avoid dereferencing ct-\u0026gt;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  \u0026lt;TASK\u0026gt;\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\u0026lt;quote\u0026gt;\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-\u0026gt;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-\u0026gt;opt_flen + opt-\u0026gt;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-\u0026gt;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-\u0026gt;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-\u0026gt;hdrlen + 1) \u0026lt;\u0026lt; 3);`\n   - It checks `CAP_NET_RAW` using `ns_capable(net-\u0026gt;user_ns,\n CAP_NET_RAW)`. (line 922)\n   - Then it does:\n     - `opt-\u0026gt;opt_flen += len;` (line 927)\n     - `opt-\u0026gt;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` =\u0026gt; `len = (255+1)*8 = 2048`\n - 1 cmsg with `hdrlen=0` =\u0026gt; `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-\u0026gt;opt_flen +\n opt-\u0026gt;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-\u0026gt;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()` -\u0026gt; `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-\u0026gt;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-\u0026gt;sdp_session()\nwith \u0026amp;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)",
  "id": "OESA-2026-2173",
  "modified": "2026-08-06T11:11:09Z",
  "published": "2026-05-03T11:11:09Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "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"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.