On Thu Jul 16, 2026 at 12:35 AM CEST, Ihor Solodrai wrote:
> On 7/9/26 3:01 AM, Alexis Lothoré (eBPF Foundation) wrote:
>> Add a basic KASAN test runner that loads and test-run programs that can
>> trigger memory management bugs. The test captures kernel logs and ensure
>> that the expected KASAN splat is emitted by searching for the
>> corresponding first lines in the report, hence validated that the needed
>> instrumentation has been inserted by the JIT compiler before the
>> relevant memory accesses. To allow each test to trigger the expected
>> report, the kernel must run with the kasan_multi_shot configuration.
>>
>> The runner covers different cases and settings: in the nominal case, it
>> validates kasan reports on basic instructions (on all supported accesses
>> sizes) but also when report _should not_ be emitted (eg: for accesses on
>> program stack). The runner also comes with a few specialized tests that
>> are then not executed for all sizes/locations:
>> - specific atomic ops
>> - test for instructions involving different verifier states, with some
>> states flagging memory as stack, and other states as non-stack memory
>> - tests that validate the stack marking shifting when a patch is emitted
>> by the verifier (zext/rnd_hi32, constant blindind)
>>
>> A few of those tests depends on cpuv4 (load_acquire and store_release).
>>
>> # ./test_progs -a kasan
>> #165/1 kasan/st_1_not_on_stack:OK
>> #165/2 kasan/st_1_on_stack:OK
>> #165/3 kasan/st_2_not_on_stack:OK
>> #165/4 kasan/st_2_on_stack:OK
>> #165/5 kasan/st_4_not_on_stack:OK
>> #165/6 kasan/st_4_on_stack:OK
>> #165/7 kasan/st_8_not_on_stack:OK
>> #165/8 kasan/st_8_on_stack:OK
>> #165/9 kasan/stx_1_not_on_stack:OK
>> #165/10 kasan/stx_1_on_stack:OK
>> #165/11 kasan/stx_2_not_on_stack:OK
>> #165/12 kasan/stx_2_on_stack:OK
>> #165/13 kasan/stx_4_not_on_stack:OK
>> #165/14 kasan/stx_4_on_stack:OK
>> #165/15 kasan/stx_8_not_on_stack:OK
>> #165/16 kasan/stx_8_on_stack:OK
>> #165/17 kasan/ldx_1_not_on_stack:OK
>> #165/18 kasan/ldx_1_on_stack:OK
>> #165/19 kasan/ldx_2_not_on_stack:OK
>> #165/20 kasan/ldx_2_on_stack:OK
>> #165/21 kasan/ldx_4_not_on_stack:OK
>> #165/22 kasan/ldx_4_on_stack:OK
>> #165/23 kasan/ldx_8_not_on_stack:OK
>> #165/24 kasan/ldx_8_on_stack:OK
>> #165/25 kasan/simple_atomic_4_not_on_stack:OK
>> #165/26 kasan/simple_atomic_4_on_stack:OK
>> #165/27 kasan/simple_atomic_8_not_on_stack:OK
>> #165/28 kasan/simple_atomic_8_on_stack:OK
>> #165/29 kasan/load_acquire_1_not_on_stack:SKIP
>> #165/30 kasan/load_acquire_1_on_stack:SKIP
>> #165/31 kasan/load_acquire_2_not_on_stack:SKIP
>> #165/32 kasan/load_acquire_2_on_stack:SKIP
>> #165/33 kasan/load_acquire_4_not_on_stack:SKIP
>> #165/34 kasan/load_acquire_4_on_stack:SKIP
>> #165/35 kasan/load_acquire_8_not_on_stack:SKIP
>> #165/36 kasan/load_acquire_8_on_stack:SKIP
>> #165/37 kasan/store_release_1_not_on_stack:SKIP
>> #165/38 kasan/store_release_1_on_stack:SKIP
>> #165/39 kasan/store_release_2_not_on_stack:SKIP
>> #165/40 kasan/store_release_2_on_stack:SKIP
>> #165/41 kasan/store_release_4_not_on_stack:SKIP
>> #165/42 kasan/store_release_4_on_stack:SKIP
>> #165/43 kasan/store_release_8_not_on_stack:SKIP
>> #165/44 kasan/store_release_8_on_stack:SKIP
>> #165/45 kasan/ldx_patched:OK
>> #165/46 kasan/ldx_patched_on_stack:OK
>> #165/47 kasan/verifier_paths_stack_and_non_stack:OK
>> #165/48 kasan/st_blinded:OK
>> #165 kasan:OK (SKIP: 16/48)
>> Summary: 1/32 PASSED, 16 SKIPPED, 0 FAILED
>
> That's quite comprehensive, good work!
>
>>
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
>> ---
>> [...]
>> +
>> +#define MAX_LOG_SIZE (8 * 1024)
>> +#define READ_CHUNK_SIZE 256
>> +
>> +#define KASAN_PATTERN_SLAB_UAF "BUG: KASAN: slab-use-after-free " \
>> + "in bpf_prog_%02x%02x%02x%02x%02x%02x%02x%02x_%s"
>> +#define KASAN_PATTERN_REPORT "%s of size %d at addr"
>
> I don't know how feasible that is, but I think it would be good to
> have a test or two for other KASAN errors, like OOB for example.
For the record, I initially started with some real memory issues (with
kfuncks performing both OoB or UaF accesses), but I quickly switched
to the shadow memory tampering method (the poisoning kfunc surgically
modifying shadow memory) as soon as I started struggling to trigger some
cases (eg: pretty hard/close to impossible to trigger a kasan write
fault without the verifier catching it first), and so I got rid in the
process of any real access issue. But I guess I can reintroduce a few
real accesses to make sure that OoB from a prog indeed trigger a report,
even if it does not cover the whole range mentioned in the listing
above.
>> [...]
>> +
>> +SEC("tcx/ingress")
>> +int simple_atomic_on_stack(struct __sk_buff *skb)
>> +{
>> + struct kasan_write_val val;
>> +
>> + bpf_kfunc_kasan_poison(&val, sizeof(struct kasan_write_val));
>> + switch (access_size) {
>> + case 4:
>> + __sync_fetch_and_add(&val.data_4, 4);
>> + break;
>> + case 8:
>> + __sync_fetch_and_add(&val.data_8, 8);
>
> It looks like the BPF_FETCH wouldn't execute this way, because the
> result is discarded? And the whole if (is_atomic_fetch) branch in
> do_jit() is also not covered?
Hmmmm, for this prog, clang emits the following:
c3 1a f4 ff 01 00 00 00 w1 = atomic_fetch_add((u32 *)(r10 - 0xc), w1)
and despite the result being discarded, the operation is properly
instrumented and executed in my setup, I see an __asan_store4 check
being instrumented just before the jited "lock xadd $edi,0x4(%rbx)" for
this insn. As a test I tried storing and using the return value to check
the difference in the emitted code, but I get a build error:
progs/kasan.c:248:13: error: Invalid usage of the XADD return value
248 | old_val = __sync_fetch_and_add(&val->data_4, 4);
I'll dig into that. Anyway you're right about is_atomic_fetch, the
branch is not being tested here, I'll fix that.
>
> Maybe it's worth adding a test with __sync_val_compare_and_swap() into
> a poisoned map value, or something of the sort?
>
Thanks,
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
