KASAN for JIT-compiled BPF code

Alexis Lothoré has been working to add support for the kernel's memory-access checker, KASAN, to just-in-time-compiled BPF code. He spoke about that work at the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit. KASAN support is needed, he said, to help catch bugs in the BPF just-in-time (JIT) compiler. KASAN is a great tool for catching memory-management problems in the kernel, but only in code that can be monitored by it.

KASAN can identify both use-after-free bugs and out-of-bounds accesses, Lothoré said, using either software or hardware memory tagging, depending on what the hardware supports. The generic software implementation reserves a section of memory to act as a bitmap tracking whether accesses to each byte of main memory are permitted. At build time, the compiler augments all of the pointer dereferences in the kernel with calls to special __asan*() functions that check whether the referenced memory is in the right state. The kernel's various allocators are hooked to update the state of the bitmap, and to insert "red zones" before and after allocations that make it easier to catch buffer overruns.

Previously, the BPF JIT emitted pointer dereferences directly, with no calls to the appropriate __asan*() functions. So, adding support for KASAN should be as simple as patching the JIT to emit those calls where appropriate. That picture is slightly complicated by the fact that BPF programs can access different areas of memory than the main kernel code, including BPF maps, arenas, global variables, and stack memory. In particular, the BPF stack is currently treated as one big memory area, but it could potentially be modified to have red zones between each variable, to help KASAN detect incorrect accesses in more detail, Lothoré said.

He has been working on a patch to add KASAN support for JIT code since the beginning of the year, on x86 to begin with. For now, he has been focusing on the LDX and STX BPF instructions, which are basic loads and stores, respectively, even though there are other instructions that can also access memory. His code also ignores loads and stores targeting the stack for the time being. Even with only those two instructions targeted, the overhead is still pretty severe. His patch essentially turns one instruction into twelve — but Lothoré believes that can be simplified with a bit of effort.

The bulk of the overhead comes from saving and restoring registers, which José Marchesi observed may not be needed if the __asan*() functions could be inlined. Lothoré agreed that it could help in principle, but pointed out that compilers are much smarter than his code, and naive inlining would be worse. A member of the audience asked why Lothoré was doing this in the JIT, instead of adding KASAN instrumentation in the compiler or the verifier. He explained that this would require exposing a stable KASAN API, and result in BPF programs needing to be compiled differently for kernels that enable KASAN, which would be an additional pain point when setting up testing with KASAN.

Another person wanted to know whether using KASAN with the BPF JIT had turned up any bugs so far. Not yet, Lothoré said, although that is mainly because his patch hadn't landed yet, and therefore it had not been run in the large number of environments in which the kernel is tested with KASAN. The instrumentation does work, though, because KASAN can generate a report that covers BPF code.

Someone else wanted to know how to tie a KASAN report back to the BPF program that caused it. The KASAN error message will include the BPF function name, Lothoré said. Alexei Starovoitov added that if the program was compiled with BTF, you should also be able to see the file name, line number, and so on. Cupertino Miranda asked where the __asan*() functions were defined; Lothoré explained that they are part of the kernel, not part of the compiler's user-space address sanitizer.

The next steps include expanding the number of BPF instructions that his code handles, particularly atomic instructions. He wasn't sure whether those should count as a KASAN load, store, or a new kind of operation. Starovoitov opined that the atomics are unlikely to be used in a way that conceals a verifier bug, and that complete coverage of every case was unlikely to be worth it, compared to just getting coverage of basic loads and stores. Despite the limited nature of the current patch set, Lothoré's work was met with general approval by the assembled developers; it may not be long before KASAN is available for BPF code as well.