Finding and Exploiting Kernel Vulnerabilities in the eBPF Subsystem

Jailbreaking the Hivemind: Finding and Exploiting Kernel Vulnerabilities in the eBPF Subsystem

Speakers: Agostino "Van1sh" Panico

Conference: DEF CON 33 (August 2025)

YouTube: https://www.youtube.com/watch?v=TXs5F-7-2aE

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Agostino%20Panico%20-%20Jailbreaking%20the%20Hivemind%20Finding%20and%20Exploiting%20Kernel%20Vulnerabilities%20in%20the%20eBPF%20Subsystem.pdf

Editor's Note: This talk attracted substantial post-conference scrutiny. In late September 2025, Alexander Peslyak (Solar Designer) published a thread on the Openwall oss-security mailing list reporting that Linux kernel eBPF maintainers found that none of the vulnerabilities disclosed by the speaker prior to the talk constituted real security issues. The Leviathan framework promised as open source by August 2025 was not released beyond a near-empty GitHub repository. Subsequent investigation by security researchers, journalists at The Stack, and eBPF experts concluded that the research was likely substantially AI-generated. The technical content of this article summarizes what was presented at the conference while accurately representing the post-conference findings regarding the validity of the claimed work.

Overview

Agostino Panico presented a 45-minute talk at DEF CON 33 arguing that the eBPF (extended Berkeley Packet Filter) subsystem in the Linux kernel represents a massive, underappreciated attack surface. The talk introduced the Leviathan framework, described as a state-aware fuzzing and exploitation automation system targeting the eBPF verifier, JIT compiler, map subsystem, and helper functions. Eleven claimed vulnerabilities were reported to Linux maintainers prior to the talk, and live demonstrations purported to show automated vulnerability discovery and exploitation chain generation. The talk was initially well-received but subsequently found to be based on research that did not survive scrutiny from kernel maintainers or security experts. The episode has become a reference point in a broader discussion about AI-generated content in security research and conference submission review processes.

Background

▶ Watch: Fuzzing methodology for finding eBPF kernel vulnerabilities (1:31)

eBPF: A Genuinely Complex and High-Value Target

The eBPF subsystem is legitimately one of the most significant expansions of Linux kernel capability in recent years. What began as a packet filter mechanism — the "Berkeley Packet Filter" of the original 1992 BSD implementation — has grown into a general-purpose in-kernel virtual machine with applications in observability (Prometheus exporters, performance tracing), networking (Cilium, Calico), security monitoring (Falco, Tracee), and container isolation. Every major cloud provider and every significant container platform deploys eBPF-based tooling as core infrastructure.

The eBPF security model depends on the verifier, approximately 15,000 lines of C code that statically analyzes each submitted eBPF program before it is loaded into the kernel. The verifier must prove that the program cannot perform unsafe memory accesses, cannot loop indefinitely, and cannot call kernel functions it is not permitted to call. If the verifier is wrong — if it incorrectly approves a program that can corrupt kernel memory — the result is local privilege escalation to root.

The verifier's history of vulnerabilities is real and well-documented. CVE-2021-3490, CVE-2021-31829, CVE-2022-23222, and numerous others demonstrate that verifier complexity translates to exploitability. Google's Project Zero, the Rust for Linux initiative, and academic researchers at EPFL have all published genuine, high-quality eBPF verifier vulnerability research. The attack surface Panico described is real; the question is whether his specific research was.

One critical context point that Panico did not prominently address in the talk: since approximately 2022, the kernel.unprivileged_bpf_disabled sysctl has been set to 1 by default in mainline kernels and all major Linux distributions. Under this setting, only users with CAP_BPF or root can load eBPF programs. This substantially limits the exploitability of eBPF verifier vulnerabilities on modern systems — they are local privilege escalation bugs for users who already have meaningful system access, not remote or completely unprivileged attacks.

What Was Claimed

▶ Watch: Introduction: eBPF subsystem and why it's a kernel attack surface (4:37)

The Leviathan Framework

The centerpiece of the talk was the Leviathan framework, described as a modular, ML-assisted security automation platform integrating:

• State-aware fuzzing: Rather than generating random eBPF bytecode, Leviathan generates programs that specifically target known vulnerability classes in the verifier's state-tracking logic — bounds calculation, type confusion, and loop bound verification. The speaker characterized this as "surgical precision against a complex state machine."
• Verifier vulnerability catalog: Over 200 patterns catalogued from analysis of historical eBPF CVEs from 2020–2022, distilled into detection signatures. Two were shown in the slides: Pattern 47 (bound confusion via integer overflow in specific BPF instructions) and Pattern 73 (type confusion via helper argument pointer type misclassification).
• KASLR bypass primitives: Targeted information leaks to defeat kernel address space layout randomization.
• Cross-architecture JIT exploitation: The same eBPF bytecode can trigger different vulnerabilities on x86-64, ARM64, RISC-V, and PowerPC, because each architecture's JIT compiler generates different native code with potentially different security properties.
• Automated exploitation chain generation: The framework claimed to convert verifier bypass primitives into arbitrary memory read/write, then into KASLR bypass and privilege escalation chains, producing output C code ready for compilation and testing.

The Claimed Vulnerabilities

Prior to the talk, Panico reported eleven eBPF vulnerabilities to Linux maintainers under the identifiers ZD_001 through ZD_013. The claimed vulnerabilities and their CVSS scores (as reported) included:

| ID | Description | Reported CVSS |

|----|-------------|---------------|

| ZD_005 | Verifier State Pruning Bypass | 8.8 |

| ZD_003 | Helper Function Validation Bypass | 7.5 |

| ZD_010 | Speculative Execution Side-Channels | 8.2 |

| ZD_011 | Container Escape via Namespace Bypass | 8.6 |

| ZD_002 | JIT Code Generation Vulnerability | 7.8 |

| ZD_007 | Atomic Operations Memory Ordering | 7.4 |

| ZD_001 | Verifier Bounds Check Bypass | 7.2 |

| ZD_004 | Map Lifecycle Race Conditions | 7.6 |

| ZD_012 | Trampoline Memory Corruption | 7.3 |

| ZD_013 | cgroup Security Bypass | 7.1 |

| ZD_009 | BTF Type Information Corruption | 6.8 |

The claim was that these had been "thoroughly validated with proof-of-concept exploits achieving success rates ranging from 52% to 95% across kernel versions 5.4.x through 6.6.x."

The Live Demo

During the talk, Panico demonstrated Leviathan running against a self-described "vulnerable machine by design." The framework purportedly loaded ML models, generated eBPF programs targeting specific vulnerability classes, identified three actual vulnerabilities out of six initial candidates (60% generation rate, then filtered to three real bugs), and then generated complete C proof-of-concept code for each. A second demo showed the exploitation chain running across multiple test machines with a claimed 90% success rate.

Post-Conference Findings

▶ Watch: Local privilege escalation via eBPF verifier bypass (7:54)

Maintainer Review

Willy Tarreau forwarded the vulnerability reports to Linux eBPF maintainers for review. Kernel developer and Openwall founder Alexander Peslyak reported the result on the oss-security mailing list in late September 2025: the maintainers concluded that none of the eleven reported vulnerabilities constituted real security issues, and no fix was developed for any of them.

Indicators of AI Generation

Peslyak identified several patterns in the pre-conference disclosure materials that are consistent with AI-generated content:

• Reporting 11 issues simultaneously is highly unusual. Genuine eBPF verifier research typically produces one to three issues per deep analysis cycle, each requiring extensive reproduction and manual validation.
• CVSS score inconsistencies: The scores in the "Critical" range (defined as 8.5+ by CVSS standards) included a 7.5 and an 8.2 — scores that are by definition not Critical. Peslyak noted this fits the pattern of LLM content that appears precise but fails at counting and boundary conditions. A statistical analysis noted that having all 11 scores unique within a narrow range (6.8 to 8.8) was itself statistically unusual under any plausible assignment process.
• Suspiciously precise claimed success rates (52% to 95% across specific kernel version ranges) without any reproducible artifacts.
• Leviathan's GitHub repository (published as poppopjmp/Leviathan) had four commits between August 13 and August 28, containing only .gitignore, LICENSE, and a README. The README described the framework in general terms and noted the project was "TBR Mid-September 2025." The talk's final slide promised open sourcing by end of August 2025. Neither deadline was met. As of the time of reporting, no functional code was available.

Broader Expert Assessment

Chris Wysopal, chief security evangelist at Veracode, told The Stack: "Hallucinated findings often look polished — complete with CVSS tables and citations — but they collapse under replication." Dane Sherrets of HackerOne drew a comparison to presenting an unexamined medical cure. Daniel Stenberg, the maintainer of curl and libcurl, noted that approximately 20% of Curl's bug bounty submissions in the relevant period were AI-generated, describing them as "all bad, some of them very bad."

DEF CON, for its part, stated it was in contact with the speaker and committed to releasing code consistent with the talk's claims. The speaker did not respond to press inquiries.

Technical Deep Dive: The eBPF Attack Surface (What Is Real)

▶ Watch: CVE disclosures: critical eBPF kernel vulnerabilities found (17:29)

Even though the specific research did not hold up, the attack surface described is genuine and worth understanding. This section summarizes what is actually known from legitimate research.

Verifier Complexity and Historical Exploitation

The verifier's design involves abstract interpretation: it simulates execution of each eBPF instruction, maintaining a state machine that tracks the type and value range of each register. Bounds calculation bugs — where the verifier's abstract range for a value diverges from the true runtime value — have historically been the most common exploitation class.

CVE-2021-3490 (discoverable value range not correctly constrained for 32-bit operations) and CVE-2021-31829 (incorrect masking of ALU operations) are representative examples. Both converted verifier state confusion into out-of-bounds memory writes achievable from unprivileged eBPF contexts — prior to the 2022 default restriction.

JIT Compiler Bugs

The JIT compilers (there is one per supported architecture) translate verified eBPF bytecode into native machine code. Architecture-specific compilation bugs — where a valid eBPF instruction sequence produces native code that violates memory safety — represent a smaller but real class. x86-64 receives the most scrutiny due to deployment prevalence; ARM64, RISC-V, and PowerPC JITs have historically received less review.

Map Race Conditions

eBPF maps are shared data structures that allow multiple eBPF programs and userspace processes to exchange data. Map operations are generally not atomic at the application level, which has historically produced use-after-free conditions when maps are deleted or resized concurrently with access.

The unprivileged_bpf_disabled Constraint

The practical exploitability of all of these classes depends on whether the attacker can load eBPF programs in the first place. Since 2022, the default on mainline kernels and all major distributions is to require CAP_BPF (or effectively root) for eBPF program loading. This means eBPF verifier bugs on modern systems are local privilege escalation for users who already have some level of system access, not vectors for completely unprivileged attackers. In container environments where eBPF is deliberately exposed to workloads, the threat model differs.

Defensive Implications

▶ Watch: Upstream patch status and Linux kernel security response (42:29)

For system administrators: On modern Linux distributions with default settings, eBPF verifier vulnerabilities are not exploitable by unprivileged users. Verify that kernel.unprivileged_bpf_disabled=1 is set (default since kernel 5.15 on most distros). For container deployments that grant CAP_BPF to workloads, carefully evaluate whether eBPF access is necessary and what the blast radius of a verifier bypass would be in your environment.

For kernel developers: The verifier's complexity is a fundamental tension. Projects like the BPF abstract interpretation formalization effort at EPFL (the PREVAIL verifier) and the gradual introduction of eBPF verification in Rust aim to address this structurally. Review processes for new BPF feature additions should explicitly consider verifier state-machine implications.

For conference organizers: The Panico incident crystallized a known problem: the traditional conference proposal review process — evaluating abstracts and speaker reputations — cannot detect technically plausible but fabricated research. Requiring reproducible artifacts (working PoC code, CVE assignments with maintainer acknowledgment, or independently verifiable build instructions) as part of the review process would add friction but would have caught this case. DEF CON's own retrospective on the incident acknowledged the difficulty of pre-screening without going deep on technical substance.

For security researchers receiving AI-assisted reports: Cross-reference claimed CVEs against the NVD and maintainer acknowledgment. Submitted proof-of-concept code that "would not compile or run" (a description applied to materials in this case) is a significant red flag. Batch submissions of 10+ issues with similar structure and no prior researcher track record warrant heightened scrutiny.

Key Takeaways

• The eBPF attack surface is real: the verifier's 15,000-line complexity, JIT compiler architecture differences, and map race conditions have produced documented, exploitable vulnerabilities.
• Since 2022, unprivileged_bpf_disabled=1 is the default in major Linux distributions, substantially limiting the exploitability of eBPF bugs on standard systems.
• The Leviathan framework as described at DEF CON 33 did not exist in functional form. Eleven claimed vulnerabilities were reviewed by Linux maintainers and found to not constitute security issues.
• Post-conference analysis by Alexander Peslyak and other experts concluded the research was likely substantially AI-generated. The Leviathan GitHub repository contained only a README and no code.
• The incident is a reference case for the growing challenge of AI-generated vulnerability research: polished, plausible-looking output with CVSS tables and claimed success rates, which collapses under replication.
• Conference submission review processes that rely on abstract evaluation and speaker reputation alone cannot reliably detect fabricated research. Artifact requirements would add a meaningful filter.

About the Speaker

Agostino "Van1sh" Panico presented himself as an Italian security researcher with over 15 years of experience in red teaming, incident response, and reverse engineering, specializing in Windows and Linux kernel exploitation. He described himself as the author of the Leviathan framework and maintainer of a fork of the SpiderFoot OSINT platform. Post-conference, the speaker did not respond to press inquiries or release the promised framework code.