The Linux Kernel extended Berkeley Packet Filter subsystem (eBPF) is the new hot goto solution for many operational and security applications. It allows inserting small custom programs directly into the running kernel, which can provide insight into the kernel internals. There are many commercial and open source solutions these days utilizing eBPF for observability, security monitoring and enforcement and kernel hacking.

The biggest advantage of eBPF is safety: even though eBPF programs execute directly in the kernel context, a bad program can never crash the kernel or do any other harm (unlike kernel modules, for example). This is enforced by the in-kernel eBPF virtual machine, which checks all programs for bad behavior before executing them.

However, over time to make eBPF more useful and feature rich BPF helpers were introduced. BPF helpers are “canned” kernel functions, which can be called from eBPF programs. They may provide some small functionality, like getting a value from some kernel data structure or helping track kernel data across different programs.

BPF helpers are real in-kernel functions, so they are not subject to eBPF virtual machine checks. Even though the code for BPF helpers is fixed, a carefully crafted eBPF program may utilize them to introduce new unexpected in-kernel code execution paths, which may lead to security vulnerabilities. And since such code execution paths are created at runtime by eBPF users, they cannot be easily discovered by static or dynamic analysis.

This presentation provides one such example, where a BPF helper could be used to create a security vulnerability in otherwise properly written kernel code. We also explore some kernel security knobs, which could make eBPF usage safer.