CVE-2025-38280

What it actually does

When BPF JIT compilation is requested but fails (e.g., due to fault injection when bpf_jit_enable=1 without CONFIG_BPF_JIT_ALWAYS_ON), the kernel incorrectly marks the program as valid and later invokes __bpf_prog_ret0_warn during execution in paths such as cls_bpf_classify, producing a WARN_ON_ONCE.

Why it matters to the business

Kernel warnings and potential instability can occur on systems running unprivileged or containerized BPF workloads, increasing operational noise, complicating debugging, and risking availability in network-heavy or security-monitoring environments; high ecosystem prevalence of the Linux kernel amplifies exposure across many deployments.

How an attack unfolds

An attacker with local access crafts a BPF program that forces JIT failure; when the program later executes in a classifier or similar hook, the mis-marked state triggers the warning path. Listed threat actors and campaigns exploiting related Linux kernel privilege-escalation issues indicate possible interest in chaining this for denial-of-service or further abuse.

How to fix it

Upgrade linux-lts (Alpaquita:stream) to 6.6.58-r0 or newer, linux-lts (Alpaquita:23) to 6.1.62-r0 or newer, and the mainline stable tree to commit e7fb4ebee6e900899d2b2e5852c3e2eafcbcad66 or equivalent backports; rebuild and reboot systems after applying the fixed kernel packages.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or package version; attempt to load BPF programs under bpf_jit_enable=1 with fault injection disabled and verify absence of the __bpf_prog_ret0_warn warning in dmesg or kernel logs.

Typical attack path

1. Obtain local unprivileged or container access on a vulnerable kernel
2. Enable or rely on bpf_jit_enable=1 without always-on JIT config
3. Load a BPF program that triggers JIT failure via fault injection or size/complexity
4. Attach the program to a hook (e.g., traffic classifier)
5. Trigger execution to reach the warn path

How to detect it

Search kernel logs and dmesg for __bpf_prog_ret0_warn or the associated WARN_ON_ONCE stack trace involving bpf_dispatcher_nop_func and cls_bpf_classify; correlate with recent BPF program loads by untrusted users or containers; review audit logs for bpf syscall activity around the time of warnings.

What your security team should do

• Prioritize kernel upgrades on all exposed systems within the CISA-style remediation window if applicable
• Disable bpf_jit_enable or enforce CONFIG_BPF_JIT_ALWAYS_ON where JIT is required
• Monitor kernel logs for __bpf_prog_ret0_warn occurrences as an interim detection measure
• Review and restrict unprivileged BPF loading via sysctl or LSM policies