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

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

On Tue Aug 4, 2026 at 8:35 PM CEST, sashiko-bot wrote:

[...]

>> @@ -2449,6 +2583,11 @@ static int do_jit(struct bpf_verifier_env *env, struct bpf_prog *bpf_prog, int *
>>  				/* populate jmp_offset for JAE above to jump to start_of_ldx */
>>  				start_of_ldx = prog;
>>  				end_of_jmp[-1] = start_of_ldx - end_of_jmp;
>> +			} else if (!accesses_stack_only) {
>> +				err = emit_kasan_check(env, &prog, src_reg,
>> +						       insn, ip, false);
>> +				if (err)
>> +					return err;
>>  			}
>
> [Severity: High]
> Does this code emit KASAN checks for BPF_PROBE_MEM and BPF_PROBE_MEMSX
> instructions?
>
> Tracing programs frequently probe pointers that may be NULL or point to
> userspace memory using BPF_PROBE_MEM. The verifier emits these
> instructions to use the BPF exception table, which safely faults without
> crashing or logging.
>
> If emit_kasan_check() is called here unconditionally, it evaluates the
> pointer using __asan_load*, which will call kasan_report() on NULL or
> userspace pointers. Won't this bypass the exception table entirely and
> print a KASAN BUG report to dmesg for every expected invalid pointer,
> potentially causing log spam?

Aside from the usual r10/r11 complain: I am confused about why the bot
is raising this concern in an answer to the selftests patch, I guess it
should have been an answer to patch 4/9.

Anyway, no, this is not instrumenting BPF_PROBE_MEM/BPF_PROBE_MEMSX
insns, and it should not. We are in the else branch of the if
actually checking if we are dealing with PROBE_MEM/PROBE_MEMSX.

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com