Re: [PATCH bpf-next v2 1/5] bpf: dispatcher: allocate bpf_dispatcher->rw_image with vmalloc()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Uninitialized kernel memory is copied into an executable BPF dispatcher region, leaking data and creating unintended ROP/JOP gadgets.
--

--- Patch [1]: [PATCH bpf-next v2 1/5] bpf: dispatcher: allocate bpf_dispatcher->rw_image with vmalloc() ---
commit 12eba9f58f961b936cd08cfa17b30375eb214d2a
Author: Mike Rapoport (Microsoft) <rppt@kernel.org>

bpf: dispatcher: allocate bpf_dispatcher->rw_image with vmalloc()

This commit changes bpf_dispatcher->rw_image allocation to use vmalloc()
instead of bpf_jit_alloc_exec() since the rel32 offsets are calculated
against the final image, removing the need for the temporary buffer to live
in the module address range.

> diff --git a/kernel/bpf/dispatcher.c b/kernel/bpf/dispatcher.c
> index ea2d60dc1feeb..d85b3e8ad2e4e 100644
> --- a/kernel/bpf/dispatcher.c
> +++ b/kernel/bpf/dispatcher.c
> @@ -148,7 +148,10 @@ void bpf_dispatcher_change_prog(struct bpf_dispatcher *d, struct bpf_prog *from,
>  		d->image = bpf_prog_pack_alloc(PAGE_SIZE, bpf_jit_fill_hole_with_zero, false);
>  		if (!d->image)
>  			goto out;
> -		d->rw_image = bpf_jit_alloc_exec(PAGE_SIZE);
> +		/* d->rw_image doesn't need to be in module memory range, so we
> +		 * can use vmalloc.
> +		 */
> +		d->rw_image = vmalloc(PAGE_SIZE);

[Severity: High]
This isn't a bug introduced by this patch, but since we are changing the
allocation here, does this code leak uninitialized kernel memory into the
executable dispatcher image?

vmalloc() does not zero-initialize the memory, and neither did the previous
bpf_jit_alloc_exec() call. When the architecture-specific code generates the
dispatcher instructions into this buffer, it only writes a few hundred bytes.

Later, bpf_dispatcher_update() copies exactly 2048 bytes from this partially
uninitialized temporary buffer into the executable RO+X dispatcher image:

bpf_dispatcher_update()
   ...
   bpf_arch_text_copy(new, tmp, PAGE_SIZE / 2);

Could this overwrite the safe int3 trap instructions placed by
bpf_prog_pack_alloc() with random bytes from the uninitialized kernel memory,
potentially creating unintended ROP/JOP gadgets? Would it be safer to use
vzalloc() here instead?

>  		if (!d->rw_image) {
>  			bpf_prog_pack_free(d->image, PAGE_SIZE);
>  			d->image = NULL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260711-execmem-x86-rox-bpf-v0-v2-0-bfd956d35119@kernel.org?part=1