Re: [PATCH 6.12.y 6/6] bpf: Prefer dirty packs for eBPF allocations

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The BPF JIT memory accounting variable (`bpf_jit_current`) leaks when `bpf_jit_binary_pack_finalize()` fails, eventually leading to a Denial of Service for future BPF JIT allocations.
--

--- Patch [6]: [PATCH 6.12.y 6/6] bpf: Prefer dirty packs for eBPF allocations ---
commit 085581ec0f6019415f4ae6868940e7810acae213
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Subject: bpf: Prefer dirty packs for eBPF allocations

This commit modifies the pack allocator to prefer dirty packs for eBPF
allocations and clean packs for cBPF. This optimization helps avoid
triggering extra flushes when cBPF reuses a dirty pack. eBPF reuse of dirty
packs is harmless as it does not trigger flushes.

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 665f8423b7600..d9131b235f797 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -998,10 +998,10 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool
>  			goto found_free_area;
>  		/*
>  		 * cBPF reuse of a dirty pack triggers a flush, so prefer a
> -		 * clean pack for cBPF. eBPF never flushes, so pick the first
> -		 * free pack, dirty or clean.
> +		 * clean pack for cBPF. eBPF never flushes, so steer it to a
> +		 * dirty pack and keep clean packs free for cBPF.
>  		 */
> -		if (!was_classic || !pack->arch_flush_needed)
> +		if (was_classic ^ pack->arch_flush_needed)
>  			goto found_free_area;
>  		if (!fallback_pack) {
>  			fallback_pack = pack;

While reviewing this area, I noticed a separate issue in the same file:

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);
	}
...
}

[Severity: High]
This isn't a bug introduced by this patch, but does this error path leak
the JIT memory accounting (bpf_jit_current)?

When bpf_arch_text_copy() fails here, it frees the pack memory via
bpf_prog_pack_free(), but misses uncharging the module memory accounting
via bpf_jit_uncharge_modmem().

Additionally, the caller reacts to this failure by permanently skipping
the cleanup that would have reverted the counter:

arch/x86/net/bpf_jit_comp.c:bpf_int_jit_compile() {
...
			if (WARN_ON(bpf_jit_binary_pack_finalize(header, rw_header))) {
				/* header has been freed */
				header = NULL;
				goto out_image;
			}
...
}

By nullifying the header, the accounting uncharge in bpf_jit_binary_pack_free()
is skipped entirely. Can this eventually lead to a Denial of Service by
preventing future BPF JIT allocations once the global limit is reached?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-cbpf-jit-spray-hardening-6-12-y-v1-0-d8585a9aed80@linux.intel.com?part=6