Ebpf
Monthly
A soundness bug in the Linux kernel BPF verifier lets a crafted eBPF program slip past verification: when handling a 32-bit 'if w1 != 0' comparison, is_branch_taken() fails to distinguish BPF_JMP32 from BPF_JMP, wrongly reports the jump as always taken, and then tracks the wrong execution path for the rest of the program - leaving register bounds inconsistent with runtime behaviour. A local attacker who can load eBPF programs (CAP_BPF/CAP_SYS_ADMIN, or a host where kernel.unprivileged_bpf_disabled has been turned off) can turn this into memory corruption and kernel privilege escalation, with the assessed CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.0) rating high confidentiality, integrity and availability impact. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis; practical risk is strongly limited by the default posture of disabling unprivileged BPF on modern distributions.
Memory-safety flaw in the Linux kernel BPF verifier (CVE-2026-93125) lets a local attacker who can load BPF programs pass a rdonly_buf_size/rdwr_buf_size kfunc argument larger than U32_MAX, causing check_kfunc_args() to store the unbounded 64-bit value in meta->r0_size and check_kfunc_call() to truncate it into the 32-bit mem_size of the returned PTR_TO_MEM register; the verifier then records a roughly 4 GiB bound for a much smaller allocation, so later access checks validate against the wrong limit and permit out-of-bounds memory reads and writes (assessed confidentiality/integrity impact low, availability impact high). The assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H: exploitation requires local access plus either CAP_BPF (supplemented by CAP_PERFMON/CAP_SYS_ADMIN depending on program type) or a system running with kernel.unprivileged_bpf_disabled=0, and only kernels from the introducing commit eb1f7f71c126 through the fixes are affected. No public exploit code has been identified and there is no confirmed active exploitation (not listed in CISA KEV) at time of analysis, though vendor patches are available.
Kernel stack corruption in the Linux kernel on RISC-V builds compiled with CONFIG_CFI_CLANG is reachable through a BPF program that performs a tail call: prog->bpf_func already lands past the kcfi instruction during setup, so folding that instruction into the tailcall jump offset again overshoots by 4 bytes and skips the stack-pointer adjustment, leaving a corrupted kernel stack. Triggering it requires a local actor able to load and run the offending BPF program (CVSS PR:L, typically CAP_BPF/CAP_SYS_ADMIN), a RISC-V kernel, and CONFIG_CFI_CLANG; non-RISC-V kernels and builds without CFI_CLANG do not execute the affected codepath. Independent assessment rates this a local, low-severity-in-practice reliability/corruption bug whose practical impact is primarily availability (crash/disrupted stack), with limited integrity impact, and no public exploit identified at time of analysis.
A type-confusion flaw in the Linux kernel BPF verifier lets a local user who is allowed to load eBPF programs (CAP_BPF or CAP_SYS_ADMIN) turn an otherwise-rejected load-acquire of a disallowed context pointer - such as the sk field of struct __sk_buff - into an unchecked raw read of the underlying kernel object, after which the register can be reused with an inconsistent pointer type. Kernels from 6.15 up to the fixed stable releases 6.18.52 and 7.2.6 (mainline 7.3-rc1) are affected. CVSS 3.1 rates it 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H); no public exploit code and no CISA KEV entry were identified at time of analysis, and real-world exposure is narrowed because unprivileged BPF is disabled by default (kernel.unprivileged_bpf_disabled=1) on mainstream distributions.
The Linux kernel eBPF verifier fails to compare the pointer type of STACK_ITER (iterator) stack slots during state pruning, so it can treat a MEM_RCU iterator slot as equivalent to a PTR_UNTRUSTED slot and prune a path that should have been rejected, allowing an unsafe BPF program to be loaded. Affected systems run Linux 6.7 through the unfixed range, with fixes landing in 7.2.6 and 7.3-rc1; the flaw requires local access plus the ability to load eBPF programs (CAP_BPF/CAP_SYS_ADMIN, or a kernel with unprivileged BPF enabled), which is why it scores CVSS 3.1 7.8 (AV:L/PR:L) with high confidentiality and integrity impact. No public exploit code and no confirmed active exploitation were identified at time of analysis, but the verifier soundness nature of the bug makes it a meaningful local privilege-escalation/kernel-sandbox-escape primitive on hosts that permit BPF loading.
A use-after-free in the Linux kernel BPF trampoline multi-attach teardown path allows a local user who already holds CAP_BPF and/or CAP_SYS_ADMIN to crash the kernel - and potentially corrupt kernel memory - by forcing bpf_trampoline_update() to abort on an error path that runs before modify_fentry_multi()/unregister_fentry_multi(), leaving the erroneous free of old_image in bpf_trampoline_multi_attach_free() to release an ftrace image that is still live. Exploitation is confined to kernels that ship the new fentry_multi trampoline code (7.2.x and the 7.3-rc series), requires privileged BPF capability plus the ability to make an update fail in that specific corner, and is not remotely reachable or available to default unprivileged users. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing); the vendor's CVSS 3.1 base score is 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), while our independent assessment scores it 6.4 (AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H), treating the realistic outcome as kernel availability loss rather than broad code execution.
Pointer-type confusion in the Linux kernel eBPF verifier allows local attackers with the ability to load eBPF programs to bypass atomic RMW pointer-type checks, potentially leading to memory corruption and high confidentiality/integrity impact (CVSS 7.8). The bug records an instruction’s pointer type only when the destination is PTR_TO_ARENA, so a second verification path can reuse the same atomic RMW instruction with an ordinary pointer without a mismatch check; the post-verification fixup then rewrites it to BPF_PROBE_ATOMIC for all paths. Affected kernels are roughly 6.10 and later with BPF arena/atomic RMW support; no public exploit was identified at time of analysis, and vendor patches are available in Linux 7.2.6 and 7.3-rc1 via commits eb287c6e and 4bc49ae3.
Linux kernel builds with HID-BPF support (CONFIG_HID_BPF) can be crashed by a race that double-releases a HID device reference: a BPF map delete invoking hid_bpf_unreg() (no BPF_F_LINK) can run concurrently with device destruction via hid_destroy_device(), so both paths call hid_put_device() on the same registration reference and the struct hid_device is freed while teardown is still executing inside hid_destroy_device(). The attacker must already hold the local privileges required to attach a HID-BPF struct_ops program (CAP_BPF/CAP_SYS_ADMIN, effectively root) and win a narrow timing window, so the independent assessment is materially lower than the vendor's 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and rates it as a crash-class fault (A:H, I:L, C:N) rather than code execution or data disclosure. No public exploit code was identified at time of analysis and the flaw is not in CISA KEV; patched stable releases (6.12.110, 6.18.51, 7.2.5, with a 7.3-rc2 fix) are available from the vendor.
Incorrect jump-offset calculation in the LoongArch BPF JIT of the Linux kernel can emit wrong tail-call branch targets, causing soft lockups (high availability impact) and, per the assessed vector, limited integrity impact, while confidentiality is unaffected. Affected are LoongArch (Loongson) systems running vulnerable kernel branches including the 6.1.x, 6.6.x, 6.12.x, 6.15.x, 6.16.x and 6.17 lines; exploitation requires local access plus the capability to load eBPF programs into the kernel (CAP_BPF or CAP_SYS_ADMIN, since unprivileged BPF is disabled by default), and only manifests when extra JIT passes occur, so it is not a deterministic single-request trigger. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the assessed severity is lower than the headline 7.8 because the flaw is architecture-specific, capability-gated and condition-dependent; vendor-released patches are available in 6.18.51, 7.2.5 and 7.3-rc1.
Integer overflow in the cilium/ebpf Go library (versions up to 0.21.0) allows a local authenticated user to cause an availability impact by supplying crafted BPF Type Format (BTF) data to the LoadCollectionSpec or LoadCollectionSpecFromReader APIs. The flaw resides in the loadRawSpec function where 32-bit header field arithmetic was performed using signed int types, enabling overflow to bypass bounds checks on StringOff, StringLen, TypeOff, and TypeLen fields. No public exploit identified at time of analysis as a KEV listing, though publicly available exploit code exists per VulDB and the CVSS temporal component E:P confirms a proof-of-concept is circulating.
A soundness bug in the Linux kernel BPF verifier lets a crafted eBPF program slip past verification: when handling a 32-bit 'if w1 != 0' comparison, is_branch_taken() fails to distinguish BPF_JMP32 from BPF_JMP, wrongly reports the jump as always taken, and then tracks the wrong execution path for the rest of the program - leaving register bounds inconsistent with runtime behaviour. A local attacker who can load eBPF programs (CAP_BPF/CAP_SYS_ADMIN, or a host where kernel.unprivileged_bpf_disabled has been turned off) can turn this into memory corruption and kernel privilege escalation, with the assessed CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.0) rating high confidentiality, integrity and availability impact. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis; practical risk is strongly limited by the default posture of disabling unprivileged BPF on modern distributions.
Memory-safety flaw in the Linux kernel BPF verifier (CVE-2026-93125) lets a local attacker who can load BPF programs pass a rdonly_buf_size/rdwr_buf_size kfunc argument larger than U32_MAX, causing check_kfunc_args() to store the unbounded 64-bit value in meta->r0_size and check_kfunc_call() to truncate it into the 32-bit mem_size of the returned PTR_TO_MEM register; the verifier then records a roughly 4 GiB bound for a much smaller allocation, so later access checks validate against the wrong limit and permit out-of-bounds memory reads and writes (assessed confidentiality/integrity impact low, availability impact high). The assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H: exploitation requires local access plus either CAP_BPF (supplemented by CAP_PERFMON/CAP_SYS_ADMIN depending on program type) or a system running with kernel.unprivileged_bpf_disabled=0, and only kernels from the introducing commit eb1f7f71c126 through the fixes are affected. No public exploit code has been identified and there is no confirmed active exploitation (not listed in CISA KEV) at time of analysis, though vendor patches are available.
Kernel stack corruption in the Linux kernel on RISC-V builds compiled with CONFIG_CFI_CLANG is reachable through a BPF program that performs a tail call: prog->bpf_func already lands past the kcfi instruction during setup, so folding that instruction into the tailcall jump offset again overshoots by 4 bytes and skips the stack-pointer adjustment, leaving a corrupted kernel stack. Triggering it requires a local actor able to load and run the offending BPF program (CVSS PR:L, typically CAP_BPF/CAP_SYS_ADMIN), a RISC-V kernel, and CONFIG_CFI_CLANG; non-RISC-V kernels and builds without CFI_CLANG do not execute the affected codepath. Independent assessment rates this a local, low-severity-in-practice reliability/corruption bug whose practical impact is primarily availability (crash/disrupted stack), with limited integrity impact, and no public exploit identified at time of analysis.
A type-confusion flaw in the Linux kernel BPF verifier lets a local user who is allowed to load eBPF programs (CAP_BPF or CAP_SYS_ADMIN) turn an otherwise-rejected load-acquire of a disallowed context pointer - such as the sk field of struct __sk_buff - into an unchecked raw read of the underlying kernel object, after which the register can be reused with an inconsistent pointer type. Kernels from 6.15 up to the fixed stable releases 6.18.52 and 7.2.6 (mainline 7.3-rc1) are affected. CVSS 3.1 rates it 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H); no public exploit code and no CISA KEV entry were identified at time of analysis, and real-world exposure is narrowed because unprivileged BPF is disabled by default (kernel.unprivileged_bpf_disabled=1) on mainstream distributions.
The Linux kernel eBPF verifier fails to compare the pointer type of STACK_ITER (iterator) stack slots during state pruning, so it can treat a MEM_RCU iterator slot as equivalent to a PTR_UNTRUSTED slot and prune a path that should have been rejected, allowing an unsafe BPF program to be loaded. Affected systems run Linux 6.7 through the unfixed range, with fixes landing in 7.2.6 and 7.3-rc1; the flaw requires local access plus the ability to load eBPF programs (CAP_BPF/CAP_SYS_ADMIN, or a kernel with unprivileged BPF enabled), which is why it scores CVSS 3.1 7.8 (AV:L/PR:L) with high confidentiality and integrity impact. No public exploit code and no confirmed active exploitation were identified at time of analysis, but the verifier soundness nature of the bug makes it a meaningful local privilege-escalation/kernel-sandbox-escape primitive on hosts that permit BPF loading.
A use-after-free in the Linux kernel BPF trampoline multi-attach teardown path allows a local user who already holds CAP_BPF and/or CAP_SYS_ADMIN to crash the kernel - and potentially corrupt kernel memory - by forcing bpf_trampoline_update() to abort on an error path that runs before modify_fentry_multi()/unregister_fentry_multi(), leaving the erroneous free of old_image in bpf_trampoline_multi_attach_free() to release an ftrace image that is still live. Exploitation is confined to kernels that ship the new fentry_multi trampoline code (7.2.x and the 7.3-rc series), requires privileged BPF capability plus the ability to make an update fail in that specific corner, and is not remotely reachable or available to default unprivileged users. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing); the vendor's CVSS 3.1 base score is 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), while our independent assessment scores it 6.4 (AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H), treating the realistic outcome as kernel availability loss rather than broad code execution.
Pointer-type confusion in the Linux kernel eBPF verifier allows local attackers with the ability to load eBPF programs to bypass atomic RMW pointer-type checks, potentially leading to memory corruption and high confidentiality/integrity impact (CVSS 7.8). The bug records an instruction’s pointer type only when the destination is PTR_TO_ARENA, so a second verification path can reuse the same atomic RMW instruction with an ordinary pointer without a mismatch check; the post-verification fixup then rewrites it to BPF_PROBE_ATOMIC for all paths. Affected kernels are roughly 6.10 and later with BPF arena/atomic RMW support; no public exploit was identified at time of analysis, and vendor patches are available in Linux 7.2.6 and 7.3-rc1 via commits eb287c6e and 4bc49ae3.
Linux kernel builds with HID-BPF support (CONFIG_HID_BPF) can be crashed by a race that double-releases a HID device reference: a BPF map delete invoking hid_bpf_unreg() (no BPF_F_LINK) can run concurrently with device destruction via hid_destroy_device(), so both paths call hid_put_device() on the same registration reference and the struct hid_device is freed while teardown is still executing inside hid_destroy_device(). The attacker must already hold the local privileges required to attach a HID-BPF struct_ops program (CAP_BPF/CAP_SYS_ADMIN, effectively root) and win a narrow timing window, so the independent assessment is materially lower than the vendor's 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and rates it as a crash-class fault (A:H, I:L, C:N) rather than code execution or data disclosure. No public exploit code was identified at time of analysis and the flaw is not in CISA KEV; patched stable releases (6.12.110, 6.18.51, 7.2.5, with a 7.3-rc2 fix) are available from the vendor.
Incorrect jump-offset calculation in the LoongArch BPF JIT of the Linux kernel can emit wrong tail-call branch targets, causing soft lockups (high availability impact) and, per the assessed vector, limited integrity impact, while confidentiality is unaffected. Affected are LoongArch (Loongson) systems running vulnerable kernel branches including the 6.1.x, 6.6.x, 6.12.x, 6.15.x, 6.16.x and 6.17 lines; exploitation requires local access plus the capability to load eBPF programs into the kernel (CAP_BPF or CAP_SYS_ADMIN, since unprivileged BPF is disabled by default), and only manifests when extra JIT passes occur, so it is not a deterministic single-request trigger. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the assessed severity is lower than the headline 7.8 because the flaw is architecture-specific, capability-gated and condition-dependent; vendor-released patches are available in 6.18.51, 7.2.5 and 7.3-rc1.
Integer overflow in the cilium/ebpf Go library (versions up to 0.21.0) allows a local authenticated user to cause an availability impact by supplying crafted BPF Type Format (BTF) data to the LoadCollectionSpec or LoadCollectionSpecFromReader APIs. The flaw resides in the loadRawSpec function where 32-bit header field arithmetic was performed using signed int types, enabling overflow to bypass bounds checks on StringOff, StringLen, TypeOff, and TypeLen fields. No public exploit identified at time of analysis as a KEV listing, though publicly available exploit code exists per VulDB and the CVSS temporal component E:P confirms a proof-of-concept is circulating.