OESA-2026-4038 (CVE-2026-52924)

Vulnerability from osv_openeuler – Published: 2026-09-25 01:27 – Updated: 2026-09-25 01:27 – 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:

sctp: purge outqueue on stale COOKIE-ECHO handling

sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed.

However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk.

During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state.

Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free().

This results in crashes such as (reported by Yuqi):

BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10

Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart.

Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.(CVE-2026-52924)

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

ipv6: mcast: Fix potential UAF in MLD delayed work

A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work.

During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU.

Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0.

However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic.

Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.(CVE-2026-72322)

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

ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD

addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list).

addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry:

general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40

Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.(CVE-2026-74398)

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

ip6_tunnel: clear skb2->cb[] in ip6ip6_err()

ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6_send(). The clone still carries the outer packet's inet6_skb_parm in skb->cb.

If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skb_pull(). icmpv6_send() later calls mip6_addr_swap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skb_shared_info.

Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack.(CVE-2026-74597)

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

inet: frags: publish queues before arming timer

inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published.

The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference.

Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.(CVE-2026-74662)

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

macvlan: inherit needed_headroom and needed_tailroom from lowerdev

macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0.

When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space.

This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom.

Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.(CVE-2026-74743)

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

ipvlan: inherit needed_headroom and needed_tailroom from phy_dev

ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0.

When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space.

This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom.

Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.(CVE-2026-74744)

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

serial: amba-pl011: synchronize DMA teardown

dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock.

Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.(CVE-2026-80737)

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

HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature

sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write.

HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.(CVE-2026-89729)

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2609.3.0.0391.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2609.3.0.0391.oe2003sp4"
            }
          ],
          "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\nsctp: purge outqueue on stale COOKIE-ECHO handling\n\nsctp_stream_update() is only invoked when the association is moved into\nCOOKIE_WAIT during association setup/reconfiguration. In this path, the\noutbound stream scheduler state (stream-\u0026gt;out_curr) is expected to be\nclean, since no user data should have been transmitted yet unless the\nstate machine has already partially progressed.\n\nHowever, a corner case exists in sctp_sf_do_5_2_6_stale(): when a\nStale Cookie ERROR is received, the association is rolled back from\nCOOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already\nhave been queued and even bundled with the COOKIE-ECHO chunk.\n\nDuring the rollback, sctp_stream_update() frees the old stream table\nand installs a new one, but it does not invalidate stream-\u0026gt;out_curr.\nAs a result, out_curr may still point to a freed sctp_stream_out\nentry from the previous stream state.\n\nLater, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on\nstream-\u0026gt;out_curr-\u0026gt;ext, which can lead to use-after-free once the old\nstream state has been released via sctp_stream_free().\n\nThis results in crashes such as (reported by Yuqi):\n\n  BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140\n  Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312\n  CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted\n     7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full)\n   sctp_sched_fcfs_dequeue+0x13a/0x140\n   sctp_outq_flush+0x1603/0x33e0\n   sctp_do_sm+0x31c9/0x5d30\n   sctp_assoc_bh_rcv+0x392/0x6f0\n   sctp_inq_push+0x1db/0x270\n   sctp_rcv+0x138d/0x3c10\n\nFix this by fully purging the association outqueue when handling the\nStale Cookie case. This ensures all pending transmit and retransmit\nstate is dropped, and any scheduler cached pointers are invalidated,\nmaking it safe to rebuild stream state during COOKIE_WAIT restart.\n\nUpdating only stream-\u0026gt;out_curr would be insufficient, since queued\nand retransmittable data would still reference the old stream state and\ntrigger later use-after-free in dequeue paths.(CVE-2026-52924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: Fix potential UAF in MLD delayed work\n\nA race condition exists between device teardown and incoming MLD query\nprocessing, leading to a Use-After-Free in the MLD delayed work.\n\nDuring device destruction, the primary reference to inet6_dev is dropped,\nwhich can drop its refcount to 0. The actual freeing of inet6_dev memory\nis deferred via RCU.\n\nConcurrently, the packet receive path runs under RCU read lock and obtains\nthe inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can\nsafely dereference inet6_dev even if its refcount has hit 0.\n\nHowever, if CPU-0 calls igmp6_event_query() and schedules delayed work, it\nattempts to acquire a reference using in6_dev_hold(). This increments the\nrefcount from 0 to 1, triggering a \u0026quot;refcount_t: addition on 0\u0026quot; warning.\nSince the inet6_dev memory is still scheduled to be freed after the RCU\ngrace period, the device is freed while the work is still scheduled.\nWhen the work runs, it accesses the freed memory, causing a kernel panic.\n\nFix this by using refcount_inc_not_zero() (via a new helper\nin6_dev_hold_safe()) to prevent acquiring a reference if the device is\nalready being destroyed. If the refcount is 0, we do not schedule the work.(CVE-2026-72322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD\n\naddrconf_dad_failure() transitions ifp-\u0026gt;state from DAD to POSTDAD\nvia addrconf_dad_end(), which drops ifp-\u0026gt;lock on return.  The lock\nis re-acquired after net_info_ratelimited().  A concurrent\nipv6_del_addr() can take the lock in that window, set ifp-\u0026gt;state\nto DEAD and run list_del_rcu(\u0026amp;ifp-\u0026gt;if_list).\n\naddrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:\nand schedules a new dad_work.  The work calls ipv6_del_addr()\nagain, hitting the already-poisoned list entry:\n\n  general protection fault: 0000 [#1] SMP NOPTI\n  CPU: 4 PID: 217 Comm: kworker/4:1\n  Workqueue: ipv6_addrconf addrconf_dad_work\n  RIP: 0010:ipv6_del_addr+0xe9/0x280\n  RAX: dead000000000122\n  Call Trace:\n   addrconf_dad_stop+0x113/0x140\n   addrconf_dad_work+0x28c/0x430\n   process_one_work+0x1eb/0x3b0\n   worker_thread+0x4d/0x400\n   kthread+0x104/0x140\n   ret_from_fork+0x35/0x40\n\nFold the addrconf_dad_end() logic into addrconf_dad_failure() under\na single ifp-\u0026gt;lock critical section.  The STABLE_PRIVACY branch\ntemporarily drops ifp-\u0026gt;lock around address regeneration, so at\nlock_errdad: verify the state is still POSTDAD before transitioning\nto ERRDAD; bail out otherwise to avoid overwriting a state set by\nanother path while the lock was released.(CVE-2026-74398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_tunnel: clear skb2-\u0026gt;cb[] in ip6ip6_err()\n\nip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the\nquoted inner IPv6 packet, and then passes the clone to icmpv6_send().\nThe clone still carries the outer packet\u0026apos;s inet6_skb_parm in skb-\u0026gt;cb.\n\nIf the outer packet had a Home Address Option, IP6CB(skb2)-\u0026gt;dsthao\nremains non-zero after skb_pull(). icmpv6_send() later calls\nmip6_addr_swap(), which uses that stale dsthao offset against the quoted\ninner packet. A malformed inner destination-options header can then make\nthe HAO lookup and address swap run past the end of the quoted packet\nand corrupt skb_shared_info.\n\nClear skb2-\u0026gt;cb[] before pulling the quoted inner IPv6 packet so the\nreply path does not reuse metadata left by the outer IPv6 stack.(CVE-2026-74597)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: publish queues before arming timer\n\ninet_frag_create() arms the fragment queue timer before inserting the\nqueue into the fqdir rhashtable. If the namespace fragment timeout is\nzero or negative, the timer can run before the queue is published.\n\nThe timer callback then marks the queue complete, tries to remove a node\nthat is not in the hash table yet, and drops the anticipated hash\nreference. Creation can subsequently publish the completed queue without\nrestoring that reference, leaving a stale hash node after the caller drops\nthe remaining reference.\n\nPublish the queue first and arm the timer while holding the queue lock.\nThis makes timer expiry wait until the queue is visible in the hash table,\nso inet_frag_kill() can remove the node and balance the hash reference.(CVE-2026-74662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: inherit needed_headroom and needed_tailroom from lowerdev\n\nmacvlan devices inherit hard_header_len from lowerdev during macvlan_init(),\nbut leave needed_headroom and needed_tailroom set to 0.\n\nWhen the underlying lowerdev requires extra headroom or tailroom for\nheaders/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx\nheadroom), upper layers calculating packet headroom and tailroom fail to\nreserve sufficient space.\n\nThis can result in reallocation overhead, skb headroom underflows, or KASAN\nslab-use-after-free crashes when dev_hard_header() / macvlan_hard_header()\nprepends header data or when lower devices append tailroom.\n\nFix this by:\n1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init().\n2. Propagating needed_headroom and needed_tailroom updates to attached macvlans\n   in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.(CVE-2026-74743)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: inherit needed_headroom and needed_tailroom from phy_dev\n\nipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(),\nbut leave needed_headroom and needed_tailroom set to 0.\n\nWhen the underlying phy_dev (or stacked lower device) requires extra headroom\nor tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or\nveth with rx headroom), upper layers calculating packet headroom and tailroom\nfail to reserve sufficient space.\n\nThis can result in reallocation overhead, skb headroom underflows, or KASAN\nslab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header()\nprepends header data or when lower devices append tailroom.\n\nFix this by:\n1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init().\n2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans\n   in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.(CVE-2026-74744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: amba-pl011: synchronize DMA teardown\n\ndmaengine_terminate_all() does not wait for a running callback, so the TX\ncallback can still touch the TX buffer after it is freed. The RX poll\ntimer reads the RX buffers without the port lock.\n\nSwitch to dmaengine_terminate_sync() and delete the RX timer before\nfreeing the buffers.(CVE-2026-80737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature\n\nsensor_hub_get_feature() clamps its return value to the caller\u0026apos;s buffer\nsize, but the copy loop still copies field-\u0026gt;report_size / 8 bytes for\neach report value. A malicious HID descriptor can advertise a large\nfeature field size while an IIO caller supplies a small stack buffer,\nsuch as a single s32, causing an out-of-bounds write.\n\nHID core stores parsed report values in __s32 slots and clamps extracted\nvalues to 32 bits. Reject feature fields that require more than one slot\nper value, guard the total byte count calculation, and clamp each\nper-value copy to the remaining caller buffer.(CVE-2026-89729)",
  "id": "OESA-2026-4038",
  "modified": "2026-09-25T01:27:34Z",
  "published": "2026-09-25T01:27:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4038"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74398"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74597"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74662"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74743"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89729"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-52924",
    "CVE-2026-72322",
    "CVE-2026-74398",
    "CVE-2026-74597",
    "CVE-2026-74662",
    "CVE-2026-74743",
    "CVE-2026-74744",
    "CVE-2026-80737",
    "CVE-2026-89729"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.



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.