CVE-2025-22005
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk8th percentile - higher than 8% of all known CVEs
Summary
A memory leak was found in the Linux kernel's fib_check_nh_v6_gw() function for IPv6. The issue occurred after moving fib_nh_common_init() before pcpu memory allocation, leaving nhc_pcpu_rth_output uncleaned on allocation failure.
Risk Assessment
The memory leak can gradually exhaust system resources, potentially leading to performance degradation or system crash over time.
Recommendation
Immediately update the Linux kernel to a version containing the fix (commit with the solution). Monitor memory usage on systems with IPv6 enabled.
Other vulnerabilities in Linux kernel
See all- CVE-2026-98164Unknown
In the Linux kernel, KVM x86/mmu's kvm_gfn_is_write_tracked() only checks the supplied memslot, but page tracking is per-address-space and shadow pages are shared across address spaces. With SMM, a GFN can be write-tracked in one address space and appear untracked in another. The fix checks the supplied slot first, then the slot for the other address space, preventing mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and triggering a BUG in pte_list_remove().
- CVE-2026-98048Unknown
In the Linux kernel's BPF subsystem, mark_fastcall_pattern_for_call() must ensure that a matched "spill; call; fill" instruction series is not interrupted by a jump. Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills() is unsound. The fix records instructions targeted by jumps in insn_aux_data[*].jump_target and uses this flag to stop growing a pattern.
- CVE-2026-98047Unknown
In the Linux kernel's BPF subsystem, in_rbtree_lock_required_cb() only checks the innermost verifier frame, so rbtree callback restrictions disappear in a nested static subprogram call frame. The subprogram can unlock the tree, remove and drop the node being compared, then relock, leading to freed memory being linked into the tree.
- CVE-2026-98046Unknown
In the Linux kernel's BPF subsystem, bpf_btf_find_by_name_kind() returns a new BTF object fd through __btf_new_fd(), which reaches anon_inode_getfd() that can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks.
- CVE-2026-98045Unknown
In the Linux kernel, a BPF verifier vulnerability affects stack helpers that may block on filesystem reads (e.g., resolving build IDs) but were not marked as sleepable. The verifier could still allow these helpers from non-sleepable regions such as RCU or preemption-disabled sections.
- CVE-2026-98044Unknown
In the Linux kernel, the BPF verifier mishandled legacy packet-load instructions (BPF_LD_ABS/BPF_LD_IND) reached from callbacks, triggering a verifier bug warning and an -EFAULT on BPF_PROG_LOAD. A privileged program loader could trigger this issue.
- CVE-2026-98043Unknown
In the Linux kernel, the BPF verifier incorrectly inferred that a pointer with an unbounded offset is non-NULL based solely on its type. As a result, a BPF program could pass verification while a NULL pointer dereference occurred at runtime.
- CVE-2026-98042Unknown
In the Linux kernel, the BPF verifier could resurrect a scalar id dropped by collect_linked_regs() because snapshots of compared registers were taken before linked registers were collected. This could lead to range inconsistencies and precision propagation issues.
- CVE-2026-98041High
In the Linux kernel, the BPF verifier incorrectly predicted the outcome of pointer vs zero comparisons in JMP32 instructions, failing to distinguish BPF_JMP from BPF_JMP32 comparisons. This led to incorrect inference that a jump is always taken.
- CVE-2026-98040Unknown
In the Linux kernel, the BPF verifier did not mark the zero register as precise for a register-form NULL check. As a result, one path was pruned and the program could dereference a zero pointer at runtime.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw(). fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails. Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak. Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path. Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

