Re: [PATCH v7] m68k, bpf: Add initial BPF JIT compiler support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: m68k JIT triggers page fault by prematurely locking subprogram memory
--

commit fa231b58c29a2f776715a46043e7efdefca56e74
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Subject: m68k, bpf: Add initial BPF JIT compiler support

This commit introduces a BPF JIT compiler for the m68k architecture. It
generates m68k machine code targeting m68020+ processors and coldfire parts
with an mmu.

> diff --git a/arch/m68k/net/bpf_jit_comp.c b/arch/m68k/net/bpf_jit_comp.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/m68k/net/bpf_jit_comp.c
[ ... ]
> +struct bpf_prog *bpf_int_jit_compile(struct bpf_verifier_env *env, struct bpf_prog *prog)
> +{
[ ... ]
> +	if (bpf_jit_enable > 1)
> +		bpf_jit_dump(prog->len, image_size, 2, ctx.target);
> +
> +	if ((!prog->aux->func || extra_pass) && bpf_jit_binary_lock_ro(header))
> +		goto out_free_hdr;

[Severity: High]
Could this condition trigger a kernel page fault when JIT compiling BPF
programs with subprograms?

When loading a BPF program with subprograms, the BPF core invokes the JIT
compiler twice. In the first pass, prog->aux->func is NULL, but prog->is_func
is set to 1. Because this checks !prog->aux->func instead of !prog->is_func,
it evaluates to true and calls bpf_jit_binary_lock_ro() during the first
pass.

When the second pass runs, the JIT attempts to write the finalized
instructions to the already locked, read-only memory buffer, which would
trigger a page fault. 

Should this check use !prog->is_func instead?

> +
> +	prog->bpf_func = (void *)ctx.target;
> +	prog->jited = 1;
> +	prog->jited_len = image_size;
> +	goto out_off;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005185251.2422114-1-visitorckw@gmail.com?part=1