Re: [PATCH bpf-next 3/4] riscv, bpf: Adjust bpf_func to account for CFI offset in bpf_jit_free

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Error path in `bpf_jit_free()` ignores the return value of `bpf_jit_binary_pack_finalize()`, leading to a use-after-free and double-free of the `ro_header`.
- [High] The BPF JIT module memory charge is permanently leaked when `bpf_jit_binary_pack_finalize()` fails.
--

--- Patch [3]: [PATCH bpf-next 3/4] riscv, bpf: Adjust bpf_func to account for CFI offset in bpf_jit_free ---
commit 2c7946882741f9c426f80073ff738910e58599f5
Author: Pu Lehui <pulehui@huawei.com>

riscv, bpf: Adjust bpf_func to account for CFI offset in bpf_jit_free

Adjusts the BPF program entry point in bpf_jit_free() by subtracting the CFI
offset. This correctly restores the original JITed allocation address before
freeing it.

> diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
> index cbfcd287ea166..059db1adeaf8d 100644
> --- a/arch/riscv/net/bpf_jit_core.c
> +++ b/arch/riscv/net/bpf_jit_core.c
> @@ -237,6 +237,7 @@ void bpf_jit_free(struct bpf_prog *prog)
>  			kvfree(jit_data->ctx.offset);
>  			kfree(jit_data);
>  		}
> +		prog->bpf_func = (void *)prog->bpf_func - cfi_get_offset();
>  		hdr = bpf_jit_binary_pack_hdr(prog);
>  		bpf_jit_binary_pack_free(hdr, NULL);

[Severity: High]
This is a pre-existing issue, but does bpf_jit_free() ignore the return value
of bpf_jit_binary_pack_finalize() and risk a use-after-free and double-free?

When bpf_jit_binary_pack_finalize() fails, it frees the ro_header internally:

kernel/bpf/core.c:bpf_jit_binary_pack_finalize() {
    ...
	if (IS_ERR(ptr)) {
		bpf_prog_pack_free(ro_header, ro_header->size);
		return PTR_ERR(ptr);
	}
    ...
}

But here in bpf_jit_free(), the error is ignored, and bpf_jit_binary_pack_free()
is called with the same header:

arch/riscv/net/bpf_jit_core.c:bpf_jit_free() {
    ...
		hdr = bpf_jit_binary_pack_hdr(prog);
		bpf_jit_binary_pack_free(hdr, NULL);
    ...
}

kernel/bpf/core.c:bpf_jit_binary_pack_free() {
    ...
	u32 size = ro_header->size;

	bpf_prog_pack_free(ro_header, size);
    ...
}

If finalization fails, could this lead to a use-after-free read of
ro_header->size, followed by a double-free of the ro_header?

[Severity: High]
This is also a pre-existing issue, but does the error path of
bpf_jit_binary_pack_finalize() permanently leak the BPF JIT module memory
charge?

When bpf_jit_binary_pack_finalize() fails and frees ro_header, it does not
uncharge the memory:

kernel/bpf/core.c:bpf_jit_binary_pack_finalize() {
    ...
	if (IS_ERR(ptr)) {
		bpf_prog_pack_free(ro_header, ro_header->size);
		return PTR_ERR(ptr);
	}
    ...
}

In other places like bpf_int_jit_compile(), a finalization failure results in
the pointers being set to NULL and bypassing bpf_jit_binary_pack_free(), which
would normally uncharge the memory:

arch/riscv/net/bpf_jit_core.c:bpf_int_jit_compile() {
    ...
		if (WARN_ON(bpf_jit_binary_pack_finalize(...))) {
			/* ro_header has been freed */
			jit_data->ro_header = NULL;
			jit_data->header = NULL;
			goto out_free_hdr;
		}
    ...
}

Could repeated failures exhaust the JIT memory limit, resulting in a local DoS
by preventing further BPF program loading?

>  		WARN_ON_ONCE(!bpf_prog_kallsyms_verify_off(prog));
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722112754.1615201-1-pulehui@huaweicloud.com?part=3