{"schema_version":"1.7.2","id":"OESA-2025-1540","modified":"2025-05-23T13:59:57Z","published":"2025-05-23T13:59:57Z","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"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\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)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-92.0.0.97.oe2403sp1"}]}],"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"]}}],"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"}],"database_specific":{"severity":"High"}}