Ebpf Offensive

eBPF offensive research

Use this skill to research eBPF as two distinct surfaces: pre-privilege verifier/JIT/kernel attack surface, and controlled post-privilege instrumentation. Keep kernel exploitation claims separate from what a privileged BPF program can already do.

When to use

Use this skill when the task involves:

• verifier acceptance, abstract-state confusion, helper lifetime, reference tracking, or state explosion;
• JIT translation, constant blinding, native-code differential behavior, or architecture-specific lowering;
• bpf() syscall commands, union bpf_attr, program/map/link types, helpers, kfuncs, or BTF;
• libbpf, CO-RE relocations, skeleton generation, bpffs pins, or bpf_link lifetime;
• kprobe/uprobe, tracepoint, fentry/fexit, LSM, cgroup, tc, XDP, iterator, or socket hooks;
• eBPF persistence/rootkit research in a disposable lab and the corresponding visibility/cleanup tests;
• enumeration of live programs, maps, links, attachments, JIT images, and pinned objects.

Route a resulting generic kernel read/write or control-flow primitive to linux-kernel-exploitation. Route broad corpus generation that is not BPF-specific to offensive-fuzzing.

Completion standard

A completed case pins kernel and BPF policy, preserves the exact instruction/object input, captures full verifier and JIT evidence, distinguishes required privilege from impact, reproduces across a controlled kernel matrix, and proves cleanup of every program, map, link, pin, and hook.

Core workflow

1. Freeze kernel, policy, and toolchain identity

Capture facts before loading a program:

uname -a
cat /etc/os-release
cat /proc/cmdline
bpftool version
clang --version
llc --version 2>/dev/null
cat /proc/sys/kernel/unprivileged_bpf_disabled 2>/dev/null
cat /proc/sys/net/core/bpf_jit_enable 2>/dev/null
cat /proc/sys/net/core/bpf_jit_harden 2>/dev/null
cat /proc/sys/net/core/bpf_jit_kallsyms 2>/dev/null
cat /sys/kernel/security/lockdown 2>/dev/null

Preserve the exact kernel image, config, vmlinux, modules, BTF blob, symbols, libbpf commit/version, bpftool build, clang/LLVM version, architecture, and boot line. Hash generated BPF ELF objects and raw instruction streams.

Record relevant configuration: CONFIG_BPF, CONFIG_BPF_SYSCALL, CONFIG_BPF_JIT, CONFIG_BPF_JIT_ALWAYS_ON, CONFIG_BPF_UNPRIV_DEFAULT_OFF, CONFIG_DEBUG_INFO_BTF, CONFIG_DEBUG_INFO_BTF_MODULES, CONFIG_CGROUP_BPF, CONFIG_BPF_LSM, CONFIG_KPROBE_EVENTS, CONFIG_UPROBE_EVENTS, CONFIG_FTRACE, CONFIG_KASAN, and CONFIG_KCOV.

Capability rules vary by kernel and operation. Record effective/permitted/ambient capabilities, user and network namespaces, LSM policy, seccomp, container context, and whether the operation relies on CAP_BPF, CAP_PERFMON, CAP_NET_ADMIN, or legacy CAP_SYS_ADMIN fallback.

2. Inventory the live BPF surface

Run privileged and unprivileged views separately when the case permits:

bpftool -j feature probe > feature.json
bpftool -j prog show > programs.before.json
bpftool -j map show > maps.before.json
bpftool -j link show > links.before.json
bpftool -j net show > net.before.json
bpftool -j cgroup tree > cgroups.before.json
find /sys/fs/bpf -xdev -printf '%y %m %u %g %p -> %l\n' > bpffs.before.txt 2>/dev/null

An empty unprivileged listing does not prove no BPF objects exist. Preserve permission errors and compare with an appropriately privileged view. Record bpffs mount namespace, tracefs/debugfs mounts, network namespace, cgroup hierarchy, and all pin paths.

For each program retain ID, tag, type, name, load time, UID, map IDs, BTF ID, JIT status/size, memlock, and attachment. For each map retain type, key/value sizes, maximum entries, flags, BTF key/value types, owner program, pins, and freeze state. For each link retain type, target, owning program, pin, and expected detach semantics.

3. Choose the research lane

State one lane before changing state:

Do not report privileged policy manipulation as a privilege escalation. Do not describe an unavailable unprivileged path as exposed merely because the kernel contains the program type.

4. Model verifier state precisely

The verifier reasons about instructions, not C source. Preserve the final instruction stream after compiler optimizations and relocations. Track:

• registers R0 through R10, scalar bounds, signed/unsigned ranges, and tnum known bits;
• pointer class, fixed/variable offset, object ID, nullability, and bounds;
• stack slot initialization, spilled pointer type, and 512-byte stack constraints;
• reference acquisition/release, dynptr/ring-buffer ownership, and callback boundaries;
• control-flow joins, state pruning, precision marks, loop bounds, subprogram calls, and tail calls;
• 32-bit versus 64-bit ALU semantics and sign/zero extension;
• helper/kfunc prototypes, BTF types, allowed program types, sleepable context, and RCU rules.

Capture the complete verifier log at a level sufficient to show the decisive state transition. Keep accepted and rejected controls that differ by one intentional property. A verifier rejection string alone does not explain root cause.

When reducing a case, preserve:

1. the same kernel outcome;
2. the same decisive verifier state;
3. the same privilege and program type;
4. the same JIT/interpreter setting;
5. one nearby negative control.

5. Build a minimal libbpf/CO-RE harness

Compile with debug and BTF information, then inspect before loading:

mkdir -p build
clang -O2 -g -target bpf -D__TARGET_ARCH_x86 \
  -c src/probe.bpf.c -o build/probe.bpf.o
llvm-objdump -S -r build/probe.bpf.o > build/probe.disasm.txt
bpftool btf dump file build/probe.bpf.o format raw > build/probe.btf.txt
bpftool gen skeleton build/probe.bpf.o > build/probe.skel.h

Pin the target architecture macro to the actual build. Preserve .BTF, .BTF.ext, maps, license, program sections, relocations, and libbpf loader logs.

CO-RE relocations depend on target BTF and field/type existence. Record each relocation outcome and distinguish a compile-time source assumption from a load-time CO-RE adaptation. Treat bpf_core_field_exists and flavor matching as explicit compatibility branches, not silent portability.

For verifier research, support a raw BPF_PROG_LOAD path that supplies exact struct bpf_insn bytes, program type, expected attach type, license, flags, log buffer, BTF IDs, and attach BTF ID. The ELF/libbpf path and raw-instruction path answer different questions.

6. Compare verifier, interpreter, and JIT outcomes

Where the kernel supports controlled toggling, preserve the original sysctl values and restore them after testing. Reboot when BPF_JIT_ALWAYS_ON or policy makes toggling invalid.

For a loaded program capture translated and native forms:

bpftool prog dump xlated id "$PROG_ID" opcodes linum > xlated.txt
bpftool prog dump jited id "$PROG_ID" opcodes linum > jited.txt

Compare:

• accepted/rejected result and verifier log;
• BPF_PROG_TEST_RUN output and context mutation where supported;
• interpreter versus JIT result on identical inputs;
• constant blinding and JIT hardening modes;
• emitted native bounds checks, speculation barriers, calls, tail calls, and exits;
• architecture-specific branch ranges, immediate materialization, and exception behavior.

Do not infer exploitable native code from a textual disassembly mismatch. Prove a semantic divergence, reachable memory-safety effect, or kernel invariant violation with a minimized input and control.

7. Investigate helper, map, and lifetime boundaries

For each helper or kfunc record:

• exact prototype and BTF type;
• permitted program/attach types and GPL restriction;
• pointer ownership before and after the call;
• null/error behavior and scalar bounds;
• RCU, lock, preemption, and sleepability context;
• reference release required on every exit path;
• kernel objects reached from map values, dynptrs, sockets, tasks, or local storage.

Map behavior is type-specific. Account for per-CPU values, LRU eviction, preallocation, mmap support, spin locks, timers, bloom filters, queues/stacks, ring buffers, map-in-map lifetime, object pinning, and freeze semantics.

For ring buffers, handle reservation failure, exact-size submission/discard, wakeup policy, consumer position, and lost-data accounting. A userspace consumer that cannot keep up is part of the experiment, not noise.

8. Attach one hook with explicit ownership

Select the narrowest hook matching the question:

Prefer bpf_link-based attachment because ownership and teardown are explicit. Document whether closing the link detaches, whether the link is pinned, and whether a legacy attach survives the loader process.

Before attaching, subscribe to the exact expected event or test signal. Trigger one controlled operation, collect one correlated record, then run a negative control. Avoid broad always-on hooks while developing the schema.

9. Separate post-root capability from stealth claims

In a disposable post-root lab, evaluate observation or policy behavior as a measured hook experiment:

• process/file/network event source and blind spots;
• map or ring-buffer command/state channel semantics;
• link and pin persistence across loader exit, namespace exit, service restart, and reboot;
• visibility from bpftool, procfs/sysfs, tracefs, audit, EDR, and memory acquisition;
• exact detach and object-release behavior.

Do not assume a renamed program, unpinned object, or absent bpftool output is hidden. IDs, tags, JIT memory, references, attachments, map contents, audit records, and kernel-memory artifacts may remain observable.

10. Fuzz and minimize deterministically

A verifier/JIT campaign records generator seed, instruction count, program type, flags, privilege, kernel hash, CPU, JIT mode, and timeout. Keep generation type-aware enough to reach deep verifier states, while retaining raw mutation for parser and boundary cases.

Useful harness paths include:

• syzkaller descriptions for bpf() commands and related object lifetimes;
• BPF_PROG_LOAD instruction generators with verifier-log capture;
• differential runs across adjacent kernel commits or architectures;
• BPF_PROG_TEST_RUN for repeatable context/data inputs;
• KASAN/KMSAN/KCOV kernels for diagnosis, followed by production-like confirmation.

Minimize on the earliest stable signal: verifier divergence, warning, KASAN report, lockdep report, JIT/interpreter mismatch, or deterministic wrong result. Preserve a bounded timeout tied to process completion or a kernel event; do not use arbitrary polling sleeps.

11. Verify cleanup and residual state

Inventory after every case with the same privileged namespace view used for the baseline:

bpftool -j prog show > programs.after.json
bpftool -j map show > maps.after.json
bpftool -j link show > links.after.json
bpftool -j net show > net.after.json
bpftool -j cgroup tree > cgroups.after.json
find /sys/fs/bpf -xdev -printf '%y %m %u %g %p -> %l\n' > bpffs.after.txt 2>/dev/null

Close loader FDs, destroy links, detach legacy hooks, remove owned pins, stop consumers, remove tc/XDP attachments, and unmount only mounts created by the case. Compare before/after IDs, tags, targets, and pins. Account for ID reuse by matching more than the numeric ID.

Restore sysctls, resource limits, network namespace/device state, cgroup attachments, qdiscs, and debug mounts. If a verifier/JIT case may have corrupted kernel state, restore the VM snapshot rather than trusting in-place cleanup.

Key structures & interfaces

• struct bpf_insn: opcode, destination/source registers, signed offset, and immediate; wide immediates occupy two instruction slots.
• union bpf_attr: command-specific syscall contract for program, map, BTF, link, test-run, and ID operations.
• bpf_prog, bpf_prog_aux, bpf_verifier_env, bpf_verifier_state, and register state: verifier and loaded-program ownership.
• bpf_map and map-type implementations: key/value geometry, refcounts, memory accounting, callbacks, and pin ownership.
• bpf_link and legacy attachment APIs: durable relationship between program and target.
• BTF type graph plus .BTF.ext: function/line info and CO-RE relocation records.
• bpf_object, bpf_program, bpf_map, and bpf_link in libbpf: userspace ownership and error paths.
• perf event array and BPF ring buffer: output ordering, backpressure, loss, and consumer lifecycle.
• helpers, kfuncs, dynptrs, local storage, timers, and refcounted kernel pointers: type-specific lifetime boundaries.
• bpffs pins, program/map/link IDs, tags, and JIT images: live-state and forensic identities.

Tooling

Evidence outputs

target.md          kernel/config/BTF/toolchain/policy/capabilities and hashes
surface.before/    programs, maps, links, hooks, cgroups, pins, mount namespaces
case/              source, ELF, raw instructions, schemas, seed, verifier log
jit/               translated/native dumps, settings, inputs, differential result
runs.jsonl         kernel, privilege, JIT mode, expected/observed outcome, timing
surface.after/     matching inventory plus cleanup diff and residual explanation

Keep verifier logs and object files together; compiler source without final instructions is not a reproducible verifier case.

Pitfalls & OPSEC

• Do not confuse privileged BPF policy control with a pre-privilege kernel exploit.
• Do not claim exposure without proving program type, attach type, capabilities, namespaces, sysctls, seccomp, lockdown, and LSM permit the path.
• Do not compare C source when verifier behavior depends on optimized instructions and relocations.
• Do not change JIT sysctls on a shared host; preserve prior values and use disposable kernels for unsafe cases.
• Do not assume verifier acceptance means safe runtime behavior or verifier rejection means no JIT/parser exposure.
• Do not trust empty unprivileged bpftool output as a complete inventory.
• Do not leak pointer-bearing verifier logs, map contents, BTF internals, or host identifiers into public artifacts.
• Avoid trace recursion, unbounded event output, and consumers that silently drop ring-buffer records.
• Pins and legacy attachments can outlive the loader; process exit is not cleanup proof.
• Program IDs can be reused; compare tags, type, load time, maps, BTF, and targets.
• Instrumented kernels change timing and layout; reproduce on a production-like target before impact claims.
• Snapshot rollback is mandatory after suspected JIT or kernel-memory corruption.

Routing

• Route a proven generic kernel corruption, read/write, page-table, credential, or ROP primitive to batch-B sibling linux-kernel-exploitation.
• Route post-root Linux host enumeration, credential provenance, persistence assessment, or pivots to batch-B sibling linux-host-post-exploitation.
• Route custom agent use of eBPF telemetry or modules to batch-B sibling c2-implant-engineering.
• Route COFF/BOF modules to batch-A sibling bof-coff-development.
• Route Windows RPC, COM, DCOM, NDR, and ALPC trust boundaries to batch-A sibling windows-rpc-com-attack.
• Route Windows provider engineering and ETW/WPP/TraceLogging measurement to batch-A sibling windows-telemetry-etw.
• Route Hyper-V partitions, hypercalls, VMBus, VSP/VSC, and worker processes to batch-A sibling hyper-v-offensive.
• Route broad fuzzing infrastructure to offensive-fuzzing; route detection and artifact searches to threat-hunting or memory-forensics.

Final gate

• Exact kernel, config, BTF, toolchain, BPF policy, capabilities, and namespaces are recorded.
• Raw instructions, ELF object, verifier log, program type, flags, and privilege reproduce the result.
• Verifier, interpreter, JIT, helper, and attachment claims are kept distinct.
• Positive and negative controls differ by one intentional property.
• Fuzzing and race tests use exact signals and bounded waits, not timing luck.
• Before/after inventories prove every program, map, link, pin, and hook was removed.
• Generic kernel impact is handed off only after the BPF-specific root cause is established.