CVE-2026-23319

What it actually does

Use-after-free in the Linux kernel BPF subsystem where bpf_link_put drops the refcount on shim_link->link.link to zero while cgroup_shim_find can still reference the object via tr->progs_hlist; the deferred cleanup in bpf_shim_tramp_link_release creates a window for another process to dereference the freed memory through bpf_trampoline_link_cgroup_shim.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel crashes or arbitrary code execution, resulting in denial of service, privilege escalation, or full host compromise; with over 215 days since publication and slowly rising exploit probability, unpatched kernels in production or container environments remain exposed.

How an attack unfolds

An attacker with local access crafts BPF programs and cgroup attachments that race bpf_link_put against concurrent lookups in cgroup_shim_find; the window created by deferred trampoline cleanup allows the freed shim object to be dereferenced, leading to a use-after-free that can be turned into memory corruption or control-flow hijacking.

How to fix it

Apply the upstream fix that adds an atomic non-zero refcount check inside bpf_trampoline_link_cgroup_shim before incrementing; rebuild and deploy updated kernel packages as soon as vendor fixes become available; until then, restrict untrusted local access and BPF program loading via LSM policies or seccomp.

How to confirm the fix worked

Confirm the patch is present by inspecting the bpf_trampoline_link_cgroup_shim function for the atomic refcount guard; run the provided delay-based reproducer in a test environment to verify the crash no longer occurs after millions of iterations.

Typical attack path

1. Obtain local user or container access on a vulnerable kernel
2. Load and attach BPF programs that exercise trampoline cgroup shims
3. Trigger concurrent bpf_link_put operations while cgroup_shim_find walks progs_hlist
4. Exploit the resulting use-after-free for memory corruption or code execution

How to detect it

Inspect kernel logs and crash dumps for oops or panic traces mentioning bpf_trampoline_link_cgroup_shim, bpf_shim_tramp_link_release, or progs_hlist; correlate with audit events showing unusual BPF program loads or cgroup attachments around the time of the crash.

What your security team should do

• Prioritize kernel updates for all systems that allow unprivileged BPF or cgroup operations
• Monitor vendor advisories for the exact fixed kernel versions once released
• Temporarily disable untrusted BPF loading or enforce via CAP_BPF and LSM
• Audit production workloads for direct use of cgroup BPF trampolines