Re: [PATCH bpf-next 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 vmalloc memory is copied into the executable BPF dispatcher image, creating an information leak and potential W^X bypass.
--

commit a818beebb25a7db7c07963818946c91a734b9050
Author: Mike Rapoport (Microsoft) <rppt@kernel.org>

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

This patch changes the allocation of the temporary bpf_dispatcher->rw_image
from bpf_jit_alloc_exec() to vmalloc(). This saves space in the module address
range since the temporary buffer doesn't require executable permissions.

> diff --git a/kernel/bpf/dispatcher.c b/kernel/bpf/dispatcher.c
> index b77db7413f8c7..a7a6a375cdd31 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);
>  		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 is a pre-existing issue, but does allocating this temporary buffer without
zeroing it leak uninitialized memory into the executable dispatcher image?

When bpf_dispatcher_update() updates the dispatcher, it unconditionally copies
PAGE_SIZE / 2 bytes (2048 bytes) from this buffer into the executable RO+X
image:

kernel/bpf/dispatcher.c:bpf_dispatcher_update() {
    ...
    arch_prepare_bpf_dispatcher(d->rw_image, ...);
    ...
    if (IS_ERR(bpf_arch_text_copy(new, tmp, PAGE_SIZE / 2)))
    ...
}

Since arch_prepare_bpf_dispatcher() only writes a small number of
instructions into the buffer, the rest of the 2048 bytes copied by
bpf_arch_text_copy() comes from whatever was previously in this allocation.

Could this allow malicious gadgets to be sprayed into vmalloc space from
userspace and then copied into executable memory, potentially bypassing W^X
protections?

Would it be safer to use vzalloc() here to ensure the unused portions of the
buffer are padded with zeroes?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626-execmem-x86-rox-bpf-v0-v1-0-45a0b0ed4fe9@kernel.org?part=1