Analysis of the eBPF Vulnerabilities in the Linux Kernel

Analysis of the eBPF Vulnerabilities in the Linux Kernel Rosario Rizza1,2[0009−0009−0498−8304], Riccardo Sisto1,3[0000−0002−3142−2383], and Fulvio Valenza1,4[0000−0002−8471−3029] 1DAUIN, Politecnico di Torino, Turin, Italy 2[email protected] 3[email protected] 4[email protected] Abstract. eBPF has become a fundamental part of modern Linux, offering in-kernel programmability for networking, observability, and security tasks. Its rapid expansion, however, has enlarged the kernel’s attack surface—particularly in security-critical components such as the verifier—where frequent vulnerabilities have been reported. These flaws pose significant risks to kernel stability and security. This paper conducts a study of 249 eBPF-related Common Vulnerabilities and Exposures (CVE) records published between 2014 and April 2025, considering Common Weakness Enumeration (CWE) tags, Common Vulnerability Scoring System (CVSS) severity metrics, kernel-version mappings, timing, and more, enabling a comprehensive view of long-term trends. Our investigation focuses on the temporal evolution of eBPF-related vulnerabilities, how long they remain unpatched, where they occur within the eBPF subsystem, what coding flaws cause them, and how severe and impactful they are. Keywords: eBPF ·CVE ·Linux Kernel ·Security ·Vulnerability Analysis · Verifier 1 Introduction The extended Berkeley Packet Filter (eBPF) has rapidly evolved from a packet filtering mechanism into a general-purpose execution environment embedded within the Linux kernel. It powers applications ranging from low-level observability tools (e.g., bcc,bpftrace) to security frameworks (e.g., seccomp filtering) and high-performance networking (e.g., XDP, Cilium). Its versatility, performance, and low-level integration with the kernel have favored widespread adoption and increased its popularity. However, the increasing programmability of the kernel comes at a cost: a broader attack surface. Despite significant engineering efforts to harden the eBPF runtime, vulnerabilities continue to be discovered regularly. A better understanding of where, why, and how these bugs occur is essential for improving 2 Rosario Rizza, Riccardo Sisto, and Fulvio Valenza the security of the kernel as a whole. The eBPF community is quite active in the security field, and numerous papers have been published to describe the vulnerabilities of eBPF. However, although the analysis of Common Vulnerabilities and Exposures (CVEs) database records is known to be useful to provide insights into specific classes of security issues, this kind of analysis has been done only to a limited extent for eBPF-related vulnerabilities: Mohamed et al. [10] studied 18 eBPF-related CVEs published in a limited time range to justify the development of a fuzzer. This paper performs a more thorough analysis of the 249 eBPF-related CVEs reported between 2014 and April 2025. Section 2 situates our work within the existing literature; Section 3 summarizes essential background; Section 5 outlines our data-collection and analysis methodology; Section 4 introduces the research questions, and Section 6 addresses them, by providing insights into the temporal and structural behavior of eBPF vulnerabilities; Section 7 concludes and summarizes the results obtained. 2 Related Work The analysis of CVE records (e.g. [12] [11]) is a common practice to get insights about specific security issues. To our knowledge, in the field of eBPF security, a paper by Mohamed et al. [10] presented the only prior study on eBPF security. They classified 18 eBPF-related CVEs published in the two years preceding their 2023 publication and showed that the eBPF verifier is the eBPF module most frequently compromised. This study was used to motivate the development of a fuzzer to detect new vulnerabilities affecting the eBPF verifier. It is quite limited because it just considers a few of the many eBPF-related vulnerabilities published as CVEs and a few aspects. Our study broadens the previous one in several ways. First, it enlarges the analysis time range, spanning the entire public history of eBPF CVEs (2014–April 2025). Secondly, it considers richer metadata such as CWE category, CVSS severity, vulnerable kernel versions, and more, and related statistics. Such extra data lets us observe long-term trends and gives a complete view of the history of the eBPF subsystem’s security. Our study follows an increasing research interest in eBPF security, including eBPF-focused fuzzers, such as [3] [14], proposals for hardening the eBPF subsystem, such as [17] [2], and proof-of-concept exploits of eBPF system vulnerabilities, such as [5] [7]. Related work on CVE analysis in other domains — ranging from open source software [11] to IoT firmware [12] — demonstrates that similar large-scale analyses provide valuable insights beyond the kernel context. Analysis of the eBPF Vulnerabilities in the Linux Kernel 3 3 Background 3.1 eBPF eBPF (extended Berkeley Packet Filter) [15] is a lightweight, in-kernel technology that allows user-defined bytecode to be executed within the Linux kernel. Originally introduced for packet filtering, eBPF has evolved into a general-purpose subsystem that supports a wide range of use cases, including tracing, security enforcement, and high-performance networking. Architecture Overview An eBPF program is typically loaded from user space via the bpf() system call. Upon loading, the program is verified by the eBPF verifier, which ensures safe and secure execution properties such as memory safety, bounded loops, and safe access to kernel data. Once verified, the program may be interpreted and executed by the eBPF virtual machine, or compiled to native code by a JIT compiler, depending on the architecture and system configuration. Programs interact with kernel subsystems through a restricted set of helper functions, which serve as an API boundary between eBPF code and kernel internals. In order to interact with the user space, special data structures, called maps, are used. Security Model The eBPF verifier enforces a strict set of rules to guarantee that programs cannot crash the kernel, access invalid memory, or perform privileged operations. However, due to the complexity of static verification and the evolving nature of eBPF features, the verifier and related components have become a recurring source of security vulnerabilities. In some cases, flaws in the verifier or helper functions have allowed unprivileged users to escalate privileges or corrupt kernel memory [7]. In order to run eBPF, the Linux capability CAP_BPF is required, with additional capabilities such as CAP_NET_ADMIN for networking hooks or CAP_PERFMON for performance tracing; while unprivileged eBPF mode exists, it is disabled by default on most mainstream distributions. 3.2 CVEs Modern vulnerability tracking relies on a layered taxonomy maintained by MITRE . At the root sits the Common Vulnerabilities and Exposures (CVE) list, which assigns a unique identifier to every publicly disclosed security flaw, ensuring that vendors, researchers, and tooling refer to the same issue unambiguously [9]. Each CVE record is then often enriched by two companion schemes. The Common Platform Enumeration (CPE) catalog provides a structured name for every affected product or version, allowing a CVE to specify its exact impact range (e.g. cpe:/o:linux:linux_kernel:5.15) [8]. Meanwhile, the Common Weakness Enumeration (CWE) classifies the underlying programming fault—such as CWE-119 “Improper Memory Bounds Restriction”—so that analysts can discuss root causes independently of any particular platform [1]. 4 Rosario Rizza, Riccardo Sisto, and Fulvio Valenza Linux Kernel CVE’s management The Linux kernel community integrates this into a defined disclosure workflow [16]. New kernel issues are first reported—often under embargo—to the private linux-distros mailing list, giving major vendors time to prepare patches. The kernel security team then requests or reuses a CVE identifier and announces the vulnerability on linux-cve-announce once a patch is available. Stable-branch maintainers back-port the patch to all supported releases, while distributors map the CVE to their package versions through CPE names and publish advisories that reference the relevant CWE category. 4 Research Questions To guide our analysis of eBPF-related vulnerabilities, we formulate a set of targeted research questions in order to examine when vulnerabilities appear, how they evolve across successive kernel releases, and how long they remain unpatched—thus outlining a timeline of exposure and remediation. In parallel, we analyze eBPF vulnerabilities from three complementary perspectives: where they occur within the subsystem, what kinds of coding errors cause them, and how severe or exploitable they tend to be. – RQ1: What is the temporal distribution of eBPF-related CVEs? – RQ2: What is the trend of the number of eBPF-related CVEs affecting each Linux kernel minor version? – RQ3: How long do eBPF-related vulnerabilities remain latent in the Linux kernel before being patched? – RQ4: Which eBPF modules are most affected by eBPF-related CVEs? – RQ5: What are the most frequent CWE categories among eBPF-related CVEs? – RQ6: How severe are eBPF-related vulnerabilities and what do CVSS vector metrics reveal about their exploitation characteristics? 5 Methodology 5.1 Data Acquisition The first step of our analysis consisted of downloading the entire archive of publicly disclosed CVEs from the National Vulnerability Database (NVD), maintained by the National Institute of Standards and Technology (NIST) [13]. The dataset used was retrieved on April 29, 2025, hence it contained all the CVEs registered up to that date with the latest updates. We paired this data with the Linux official git repository metadata [6], specifically with the commit history to extrapolate the commit date and the files that were involved. Analysis of the eBPF Vulnerabilities in the Linux Kernel 5 5.2 Data Classification and Refinement To identify eBPF-related vulnerabilities, we first performed a keyword-based filtering by selecting all entries containing the substring bpf, which yielded a total of 401 CVEs. This raw subset was refined through manual inspection, classifying each entry as included,external,orexcluded.External refers to vulnerabilities affecting eBPF-related software outside the Linux kernel itself, such as user-space tools like Cilium; a total of 63 of these CVEs were found in the database. The excluded category includes cases where the term bpf appears only incidentally, but not connected to BPF, or where eBPF is merely used as a vector to trigger or exploit other vulnerabilities not inherent to eBPF internals. After this filtering, the dataset retained 249 CVEs for analysis. 6 Results and Discussion In this section, we present the results of our analysis and provide answers to the research questions introduced in the previous section. Each answer to the questions contains a note on the methodology used to extract the dimension needed for calculating the result, and the analysis of the output. 6.1 RQ1: What is the temporal distribution of eBPF-related CVEs? Fig. 1. Temporal distribution of eBPF-related CVEs, aggregated by four-month intervals. 6 Rosario Rizza, Riccardo Sisto, and Fulvio Valenza Methodology To analyze the temporal evolution of eBPF-related CVEs, we relied on their official publication dates as recorded in public vulnerability databases. For consistency and to capture trends at a suitable granularity, we aggregated CVEs into fixed four-month intervals. This grouping ensures regular spacing across the timeline and accommodates the most recent disclosures, including those from the first third of 2025. Analysis The resulting distribution reveals a general upward trend over the years, punctuated by a few early anomalies (Fig. 1). An initial bump appears around 2017, followed by relatively low but persistent activity. A more noticeable increase occurs between 2021 and 2022, and from late 2023 onward, the number of CVEs more than doubles compared to previous intervals, culminating in a peak in the first third of 2024, with over 60 new vulnerabilities reported. To better understand the long-term trend beyond short-term fluctuations, we applied a smoothed interpolation technique. The resulting curve shows a nonlinear, but clearly upward trajectory, with minor local fluctuations—including a slight rise around 2019—before accelerating more steeply in recent intervals. This trend supports the interpretation that eBPF has become an increasingly critical and exposed component in the Linux kernel. The sharp increase in the number of vulnerabilities reported in the past year may also be linked to the concurrent development and publication of new fuzzing-based techniques for systematic vulnerability discovery, such as[3] [14], as well as to the growing complexity of the verifier [4]. 6.2 RQ2: What is trend of the number of eBPF-related CVEs affecting each Linux kernel minor version? Methodology For each CVE we extracted the list of affected kernel versions — encoded in the CVE record through CPE strings — and mapped those CPE tuples to the corresponding minor-release numbers. After this step, we obtained, for the first release (and for each patch) of every Linux kernel minor version, the total number of CVEs affecting it. In Fig. 2, we plot the number of CVEs affecting the first release of every Linux Kernel minor version. Analysis Beginning with version 4.14, the count of eBPF-related CVEs affecting the first release of the version increases steadily, peaking at just over 100 in kernel 5.10, which is an LTS. The increasing trend might be favored by a growing interest and a consequent faster development in the eBPF subsystem. The most recent minor versions exhibit lower counts, probably just because they have had less time in the field for vulnerabilities to be discovered and reported. LTS versions often appear as local maxima, reflecting more active development and backporting efforts compared to adjacent non-LTS releases. Analysis of the eBPF Vulnerabilities in the Linux Kernel 7 Fig. 2. eBPF-related CVEs affecting the first release of each kernel minor version 6.3 RQ3: How long do eBPF-related vulnerabilities remain latent in the Linux kernel before being patched? Methodology For each CVE in our dataset we identified the first kernel release reported as vulnerable (from CVE metadata) and the commit that introduced the corresponding patch (from the mainline Git history). We then computed the latency, in days, between the release date of the affected version and the date the fix was merged. Descriptive statistics were produced for 70% of CVEs, i.e., the ones for which this information is available. Analysis Across the complete set, the mean time-to-fix is 1037.6 days and the median is 737 days, with a maximum of 7744 days. Removing the two longest delays reduces the mean slightly to 995 days while leaving the median unchanged, suggesting that most vulnerabilities are characterized by a broadly similar exposure window and that extreme cases have limited influence on the central tendency. No temporal pattern is apparent: both older and more recent kernel versions show a mix of vulnerabilities uncovered within weeks and others persisting for several years. The large standard deviation (about 1060 days), almost equal to the mean, confirms this wide dispersion—there is no single “typical” discovery delay, but rather a broad spectrum of latency times across the entire history of eBPF development.Moreover, there is no significant correlation between the patch latency and the CVE severity (the computed correlation is 0.06), which is concerning given the potential impact of delayed remediation for serious vulnerabilities. Among the 32 vulnerabilities with a severity score of at least 7, only 10 were fixed within the first year, and 15 within two years—meaning that more than half (17 vulnerabilities) remained unpatched for over two years after their initial release. Overall, eBPF-related vulnerabilities tend to persist in the kernel 8 Rosario Rizza, Riccardo Sisto, and Fulvio Valenza for roughly two to three years before a corrective patch is merged. This long persistence, associated with the high occurrence rate and the absence of correlation with severity, raises a warning, showing that the eBPF system could be a significant catchment area for zero-day vulnerabilities. 6.4 RQ4: Which eBPF modules are most affected by eBPF-related CVEs? Fig. 3. Top 10 eBPF subsystem modules affected by CVEs Methodology To identify which components of the eBPF subsystem are most frequently affected by security vulnerabilities, we first performed a manual classification of all eBPF-related CVEs. Each CVE was analyzed and assigned to one or more functional modules, depending on the nature of the vulnerability. The categories include: verifier (responsible for validating eBPF programs before execution), core (handling the internal logic, system calls, and virtual machine behavior), maps (managing eBPF maps), helpers (covering helper functions), kernel functions (kfuncs), JIT compiler (just-in-time translation to native instructions), BTF (providing compatibility and internal structure management), selftests (internal testing infrastructure), and various subsystems (e.g., networking, tracing, and performance hooks). Importantly, this categorization is not mutually exclusive: a single CVE may span multiple modules. For instance, a verifier flaw that fails to correctly vali- Analysis of the eBPF Vulnerabilities in the Linux Kernel 9 Fig. 4. Top 10 files most frequently modified in commits addressing eBPF-related CVEs. date access to a helper function is associated with both the verifier and helpers categories. To complement this logical classification with a source-level perspective, we further analyzed the code changes applied to fix each vulnerability. For every CVE with an associated public fix, we extracted the commit(s) from the mainline Linux kernel repository and recorded the modified source files. Even if the patched files may not always indicate the origin of the vulnerability, the two analyses yielded similar results. Analysis The manual classification, shown in Fig. 3, reveals that the verifier is the most impacted module by a significant margin, followed by the networking subsystem, the core, and the helpers and maps modules. This distribution confirms the eBPF verifier’s central role and its historical fragility in handling complex or edge-case program logic [10]. The file-level analysis shown in Fig. 4 further reinforces these findings . The most frequently modified file in CVE-related commits is verifier.c, which alone appears in nearly 70 commits — over three times more than the next file, syscall.c. Additional verifier-related files, such as bpf_verifier.h, also rank in the top 10. The top modified files are overwhelmingly located within kernel/bpf/, with a few exceptions in include/linux/ and net/core/, the latter reflecting vulnerabilities in networking integration. Overall, both the logical module-based classification and the physical sourcelevel analysis converge on the same conclusion: the eBPF verifier represents the most vulnerable and maintenance-intensive part of the eBPF subsystem. Its complexity, central role in enforcing safety, and ongoing evolution make it a persistent source of security challenges.