Re: [PATCH bpf-next v5 10/10] selftests/bpf: add tests to validate KASAN on JIT programs

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

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) <alexis.lothore@bootlin.com>
>> ---
>> [...]
>> +
>> +#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