GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2025-1540 (CVE-2024-58098)

Vulnerability from osv_openeuler – Published: 2025-05-23 11:08 – Updated: 2026-08-06 11:08 – 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:

bpf: track changes_pkt_data property for global functions

When processing calls to certain helpers, verifier invalidates all packet pointers in a current state. For example, consider the following program:

__attribute__((__noinline__))
long skb_pull_data(struct __sk_buff *sk, __u32 len)
{
    return bpf_skb_pull_data(sk, len);
}

SEC("tc")
int test_invalidate_checks(struct __sk_buff *sk)
{
    int *p = (void *)(long)sk->data;
    if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP;
    skb_pull_data(sk, 0);
    *p = 42;
    return TCX_PASS;
}

After a call to bpf_skb_pull_data() the pointer 'p' can't be used safely. See function filter.c:bpf_helper_changes_pkt_data() for a list of such helpers.

At the moment verifier invalidates packet pointers when processing helper function calls, and does not traverse global sub-programs when processing calls to global sub-programs. This means that calls to helpers done from global sub-programs do not invalidate pointers in the caller state. E.g. the program above is unsafe, but is not rejected by verifier.

This commit fixes the omission by computing field bpf_subprog_info->changes_pkt_data for each sub-program before main verification pass. changes_pkt_data should be set if: - subprogram calls helper for which bpf_helper_changes_pkt_data returns true; - subprogram calls a global function, for which bpf_subprog_info->changes_pkt_data should be set.

The verifier.c:check_cfg() pass is modified to compute this information. The commit relies on depth first instruction traversal done by check_cfg() and absence of recursive function calls: - check_cfg() would eventually visit every call to subprogram S in a state when S is fully explored; - when S is fully explored: - every direct helper call within S is explored (and thus changes_pkt_data is set if needed); - every call to subprogram S1 called by S was visited with S1 fully explored (and thus S inherits changes_pkt_data from S1).

The downside of such approach is that dead code elimination is not taken into account: if a helper call inside global function is dead because of current configuration, verifier would conservatively assume that the call occurs for the purpose of the changes_pkt_data computation.(CVE-2024-58098)

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

ocfs2: validate l_tree_depth to avoid out-of-bounds access

The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH.

Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1].(CVE-2025-22079)

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

mfd: ene-kb3930: Fix a potential NULL pointer dereference

The off_gpios could be NULL. Add missing check in the kb3930_probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f ("backlight: hx8357: Fix potential NULL pointer dereference").

This was detected by our static analysis tool.(CVE-2025-23146)

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

bpf: Fix kmemleak warning for percpu hashmap

Vlad Poenaru reported the following kmemleak issue:

unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): (void __percpu *)(l->key + key_size) = pptr;

Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.

In htab_map_alloc(), we already have

    htab->elem_size = sizeof(struct htab_elem) +
                      round_up(htab->map.key_size, 8);
    if (percpu)
            htab->elem_size += sizeof(void *);
    else
            htab->elem_size += round_up(htab->map.value_size, 8);

So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.

The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.(CVE-2025-37807)

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

LoongArch: Return NULL from huge_pte_offset() for invalid PMD

LoongArch's huge_pte_offset() currently returns a pointer to a PMD slot even if the underlying entry points to invalid_pte_table (indicating no mapping). Callers like smaps_hugetlb_range() fetch this invalid entry value (the address of invalid_pte_table) via this pointer.

The generic is_swap_pte() check then incorrectly identifies this address as a swap entry on LoongArch, because it satisfies the "!pte_present() && !pte_none()" conditions. This misinterpretation, combined with a coincidental match by is_migration_entry() on the address bits, leads to kernel crashes in pfn_swap_entry_to_page().

Fix this at the architecture level by modifying huge_pte_offset() to check the PMD entry's content using pmd_none() before returning. If the entry is invalid (i.e., it points to invalid_pte_table), return NULL instead of the pointer to the slot.(CVE-2025-37818)

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

cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()

cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scmi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.

Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.(CVE-2025-37830)

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

drm/amd/display: prevent hang on link training fail

[Why] When link training fails, the phy clock will be disabled. However, in enable_streams, it is assumed that link training succeeded and the mux selects the phy clock, causing a hang when a register write is made.

[How] When enable_stream is hit, check if link training failed. If it did, fall back to the ref clock to avoid a hang and keep the system in a recoverable state.(CVE-2025-37870)

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

perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init

Move the get_ctx(child_ctx) call and the child_event->ctx assignment to occur immediately after the child event is allocated. Ensure that child_event->ctx is non-NULL before any subsequent error path within inherit_event calls free_event(), satisfying the assumptions of the cleanup code.

Details:

There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression.

The code initially incremented refcount then assigned context immediately after the child_event was created. Later, an early validity check for child_event was added before the refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was added, assuming event->ctx is valid if the pmu_ctx is valid. The problem is that the WARN_ON_ONCE() could trigger after the initial check passed but before child_event->ctx was assigned, violating its precondition. The solution is to assign child_event->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARN_ON_ONCE().

To resolve it, defer the refcount update and child_event->ctx assignment directly after child_event->pmu_ctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmu_ctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in child_ctx to find_get_pmu_context before its refcount/assignment.

mingo: Expanded the changelog from another email by Gabriel Shahrouzi.

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

bpf: Fix deadlock between rcu_tasks_trace and event_mutex.

Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace()

There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case.

CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex)

Delegate trace_set_clr_event() to workqueue to avoid such lock dependency.(CVE-2025-37884)

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

tracing: Verify event formats that have "%*p.."

The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory.

The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses "%*p.." the verifier will ignore it, and that could be dangerous. Cover this case as well.

Also add to the sample code a use case of "%*pbl".(CVE-2025-37938)

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-debuginfo-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-debugsource-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-devel-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-headers-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-source-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-tools-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "kernel-tools-devel-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "perf-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "perf-debuginfo-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "python3-perf-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-92.0.0.97.oe2403sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-92.0.0.97.oe2403sp1.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-debuginfo-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-debugsource-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-devel-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-headers-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-source-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-tools-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "kernel-tools-devel-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "perf-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "perf-debuginfo-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "python3-perf-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-92.0.0.97.oe2403sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-92.0.0.97.oe2403sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\nbpf: track changes_pkt_data property for global functions\n\nWhen processing calls to certain helpers, verifier invalidates all\npacket pointers in a current state. For example, consider the\nfollowing program:\n\n    __attribute__((__noinline__))\n    long skb_pull_data(struct __sk_buff *sk, __u32 len)\n    {\n        return bpf_skb_pull_data(sk, len);\n    }\n\n    SEC(\u0026quot;tc\u0026quot;)\n    int test_invalidate_checks(struct __sk_buff *sk)\n    {\n        int *p = (void *)(long)sk-\u0026gt;data;\n        if ((void *)(p + 1) \u0026gt; (void *)(long)sk-\u0026gt;data_end) return TCX_DROP;\n        skb_pull_data(sk, 0);\n        *p = 42;\n        return TCX_PASS;\n    }\n\nAfter a call to bpf_skb_pull_data() the pointer \u0026apos;p\u0026apos; can\u0026apos;t be used\nsafely. See function filter.c:bpf_helper_changes_pkt_data() for a list\nof such helpers.\n\nAt the moment verifier invalidates packet pointers when processing\nhelper function calls, and does not traverse global sub-programs when\nprocessing calls to global sub-programs. This means that calls to\nhelpers done from global sub-programs do not invalidate pointers in\nthe caller state. E.g. the program above is unsafe, but is not\nrejected by verifier.\n\nThis commit fixes the omission by computing field\nbpf_subprog_info-\u0026gt;changes_pkt_data for each sub-program before main\nverification pass.\nchanges_pkt_data should be set if:\n- subprogram calls helper for which bpf_helper_changes_pkt_data\n  returns true;\n- subprogram calls a global function,\n  for which bpf_subprog_info-\u0026gt;changes_pkt_data should be set.\n\nThe verifier.c:check_cfg() pass is modified to compute this\ninformation. The commit relies on depth first instruction traversal\ndone by check_cfg() and absence of recursive function calls:\n- check_cfg() would eventually visit every call to subprogram S in a\n  state when S is fully explored;\n- when S is fully explored:\n  - every direct helper call within S is explored\n    (and thus changes_pkt_data is set if needed);\n  - every call to subprogram S1 called by S was visited with S1 fully\n    explored (and thus S inherits changes_pkt_data from S1).\n\nThe downside of such approach is that dead code elimination is not\ntaken into account: if a helper call inside global function is dead\nbecause of current configuration, verifier would conservatively assume\nthat the call occurs for the purpose of the changes_pkt_data\ncomputation.(CVE-2024-58098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: validate l_tree_depth to avoid out-of-bounds access\n\nThe l_tree_depth field is 16-bit (__le16), but the actual maximum depth is\nlimited to OCFS2_MAX_PATH_DEPTH.\n\nAdd a check to prevent out-of-bounds access if l_tree_depth has an invalid\nvalue, which may occur when reading from a corrupted mounted disk [1].(CVE-2025-22079)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: ene-kb3930: Fix a potential NULL pointer dereference\n\nThe off_gpios could be NULL. Add missing check in the kb3930_probe().\nThis is similar to the issue fixed in commit b1ba8bcb2d1f\n(\u0026quot;backlight: hx8357: Fix potential NULL pointer dereference\u0026quot;).\n\nThis was detected by our static analysis tool.(CVE-2025-23146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n  unreferenced object 0x606fd7c44ac8 (size 32):\n    backtrace (crc 0):\n      pcpu_alloc_noprof+0x730/0xeb0\n      bpf_map_alloc_percpu+0x69/0xc0\n      prealloc_init+0x9d/0x1b0\n      htab_map_alloc+0x363/0x510\n      map_create+0x215/0x3a0\n      __sys_bpf+0x16b/0x3e0\n      __x64_sys_bpf+0x18/0x20\n      do_syscall_64+0x7b/0x150\n      entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n  *(void __percpu **)(l-\u0026gt;key + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won\u0026apos;t detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n        htab-\u0026gt;elem_size = sizeof(struct htab_elem) +\n                          round_up(htab-\u0026gt;map.key_size, 8);\n        if (percpu)\n                htab-\u0026gt;elem_size += sizeof(void *);\n        else\n                htab-\u0026gt;elem_size += round_up(htab-\u0026gt;map.value_size, 8);\n\nSo storing pptr with 8-byte alignment won\u0026apos;t cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n  1. Enable CONFIG_DEBUG_KMEMLEAK config\n  2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n     The purpose is to keep map available so kmemleak can be detected.\n  3. run \u0026apos;./test_progs -t for_each/hash_map \u0026amp;\u0026apos; and a kmemleak should be reported.(CVE-2025-37807)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Return NULL from huge_pte_offset() for invalid PMD\n\nLoongArch\u0026apos;s huge_pte_offset() currently returns a pointer to a PMD slot\neven if the underlying entry points to invalid_pte_table (indicating no\nmapping). Callers like smaps_hugetlb_range() fetch this invalid entry\nvalue (the address of invalid_pte_table) via this pointer.\n\nThe generic is_swap_pte() check then incorrectly identifies this address\nas a swap entry on LoongArch, because it satisfies the \u0026quot;!pte_present()\n\u0026amp;\u0026amp; !pte_none()\u0026quot; conditions. This misinterpretation, combined with a\ncoincidental match by is_migration_entry() on the address bits, leads to\nkernel crashes in pfn_swap_entry_to_page().\n\nFix this at the architecture level by modifying huge_pte_offset() to\ncheck the PMD entry\u0026apos;s content using pmd_none() before returning. If the\nentry is invalid (i.e., it points to invalid_pte_table), return NULL\ninstead of the pointer to the slot.(CVE-2025-37818)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy-\u0026gt;cpus mask. scmi_cpufreq_get_rate() does not check for\nthis case, which results in a NULL pointer dereference.\n\nAdd NULL check after cpufreq_cpu_get_raw() to prevent this issue.(CVE-2025-37830)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: prevent hang on link training fail\n\n[Why]\nWhen link training fails, the phy clock will be disabled. However, in\nenable_streams, it is assumed that link training succeeded and the\nmux selects the phy clock, causing a hang when a register write is made.\n\n[How]\nWhen enable_stream is hit, check if link training failed. If it did, fall\nback to the ref clock to avoid a hang and keep the system in a recoverable\nstate.(CVE-2025-37870)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix WARN_ON(!ctx) in __free_event() for partial init\n\nMove the get_ctx(child_ctx) call and the child_event-\u0026gt;ctx assignment to\noccur immediately after the child event is allocated. Ensure that\nchild_event-\u0026gt;ctx is non-NULL before any subsequent error path within\ninherit_event calls free_event(), satisfying the assumptions of the\ncleanup code.\n\nDetails:\n\nThere\u0026apos;s no clear Fixes tag, because this bug is a side-effect of\nmultiple interacting commits over time (up to 15 years old), not\na single regression.\n\nThe code initially incremented refcount then assigned context\nimmediately after the child_event was created. Later, an early\nvalidity check for child_event was added before the\nrefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was\nadded, assuming event-\u0026gt;ctx is valid if the pmu_ctx is valid.\nThe problem is that the WARN_ON_ONCE() could trigger after the initial\ncheck passed but before child_event-\u0026gt;ctx was assigned, violating its\nprecondition. The solution is to assign child_event-\u0026gt;ctx right after\nits initial validation. This ensures the context exists for any\nsubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().\n\nTo resolve it, defer the refcount update and child_event-\u0026gt;ctx assignment\ndirectly after child_event-\u0026gt;pmu_ctx is set but before checking if the\nparent event is orphaned. The cleanup routine depends on\nevent-\u0026gt;pmu_ctx being non-NULL before it verifies event-\u0026gt;ctx is\nnon-NULL. This also maintains the author\u0026apos;s original intent of passing\nin child_ctx to find_get_pmu_context before its refcount/assignment.\n\n[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ](CVE-2025-37878)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix deadlock between rcu_tasks_trace and event_mutex.\n\nFix the following deadlock:\nCPU A\n_free_event()\n  perf_kprobe_destroy()\n    mutex_lock(\u0026amp;event_mutex)\n      perf_trace_event_unreg()\n        synchronize_rcu_tasks_trace()\n\nThere are several paths where _free_event() grabs event_mutex\nand calls sync_rcu_tasks_trace. Above is one such case.\n\nCPU B\nbpf_prog_test_run_syscall()\n  rcu_read_lock_trace()\n    bpf_prog_run_pin_on_cpu()\n      bpf_prog_load()\n        bpf_tracing_func_proto()\n          trace_set_clr_event()\n            mutex_lock(\u0026amp;event_mutex)\n\nDelegate trace_set_clr_event() to workqueue to avoid\nsuch lock dependency.(CVE-2025-37884)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Verify event formats that have \u0026quot;%*p..\u0026quot;\n\nThe trace event verifier checks the formats of trace events to make sure\nthat they do not point at memory that is not in the trace event itself or\nin data that will never be freed. If an event references data that was\nallocated when the event triggered and that same data is freed before the\nevent is read, then the kernel can crash by reading freed memory.\n\nThe verifier runs at boot up (or module load) and scans the print formats\nof the events and checks their arguments to make sure that dereferenced\npointers are safe. If the format uses \u0026quot;%*p..\u0026quot; the verifier will ignore it,\nand that could be dangerous. Cover this case as well.\n\nAlso add to the sample code a use case of \u0026quot;%*pbl\u0026quot;.(CVE-2025-37938)",
  "id": "OESA-2025-1540",
  "modified": "2026-08-06T11:08:38Z",
  "published": "2025-05-23T11:08:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1540"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58098"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22079"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23146"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37807"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37830"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37870"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37878"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37938"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-58098",
    "CVE-2025-22079",
    "CVE-2025-23146",
    "CVE-2025-37807",
    "CVE-2025-37818",
    "CVE-2025-37830",
    "CVE-2025-37870",
    "CVE-2025-37878",
    "CVE-2025-37884",
    "CVE-2025-37938"
  ]
}



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.


Detection rules are retrieved from Rulezet.


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.