Re: [PATCH bpf-next v2 3/5] bpf: alloc_prog_pack(): skip ROX management for already ROX memory

[Mike Rapoport <rppt@kernel.org>]

On Sat, Jul 11, 2026 at 10:00:31AM +0000, sashiko-bot@kernel.org wrote:
>
> bpf: alloc_prog_pack(): skip ROX management for already ROX memory
> 
> > @@ -965,7 +972,7 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool
> >  			pr_warn_once("BPF: Predictors not flushed for allocations greater than BPF_PROG_PACK_SIZE\n");
> >  		size = round_up(size, PAGE_SIZE);
> >  		ptr = bpf_jit_alloc_exec(size);
> > -		if (ptr) {
> > +		if (ptr && !bpf_jit_mem_is_rox()) {
> >  			int err;
> >  
> >  			bpf_fill_ill_insns(ptr, size);
> 
> [Severity: Medium]
> Since this patch protects bpf_prog_pack_alloc() and alloc_new_pack() from
> writing to memory that might already be ROX, does it also need to protect
> other callers of bpf_jit_alloc_exec() that write directly to the allocated
> memory?
> 
> For example, bpf_jit_binary_alloc() allocates memory and directly writes
> illegal instructions:
> 
> kernel/bpf/core.c:bpf_jit_binary_alloc() {
>     ...
>     hdr = bpf_jit_alloc_exec(size);
>     if (!hdr) {
>         bpf_jit_uncharge_modmem(size);
>         return NULL;
>     }
> 
>     /* Fill space with illegal/arch-dep instructions. */
>     bpf_fill_ill_insns(hdr, size);
>     ...
> }

ROX caches are only supported on x86-64, and this is never called there.
 
> Similarly, on x86, arch_bpf_trampoline_size() allocates memory and passes
> it as a read-write buffer:
> 
> arch/x86/net/bpf_jit_comp.c:arch_bpf_trampoline_size() {
>     ...
>     image = bpf_jit_alloc_exec(PAGE_SIZE);
>     if (!image)
>         return -ENOMEM;
> 
>     ret = __arch_prepare_bpf_trampoline(&im, image, image + PAGE_SIZE, image,
>                                         m, flags, tnodes, func_addr);
>     ...
> }
> 
> Could these paths cause a page fault when EXECMEM_ROX_CACHE is enabled,
> since they attempt to write directly to the read-only memory?

This is handled by the next patch.

-- 
Sincerely yours,
Mike.