Use After Free Affecting kernel-source package, versions <6.12.0-160000.28.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.01% (4th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Use After Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES1600-KERNELSOURCE-16332922
  • published1 May 2026
  • disclosed20 Apr 2026

Introduced: 20 Apr 2026

NewCVE-2026-23319  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade SLES:16.0.0 kernel-source to version 6.12.0-160000.28.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-source package and not the kernel-source package as distributed by SLES. See How to fix? for SLES:16.0.0 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim

The root cause of this bug is that when 'bpf_link_put' reduces the refcount of 'shim_link->link.link' to zero, the resource is considered released but may still be referenced via 'tr->progs_hlist' in 'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in 'bpf_shim_tramp_link_release' is deferred. During this window, another process can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'.

Based on Martin KaFai Lau's suggestions, I have created a simple patch.

To fix this: Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'. Only increment the refcount if it is not already zero.

Testing: I verified the fix by adding a delay in 'bpf_shim_tramp_link_release' to make the bug easier to trigger:

static void bpf_shim_tramp_link_release(struct bpf_link link) { / ... */ if (!shim_link->trampoline) return;

  • msleep(100); WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline); }

Before the patch, running a PoC easily reproduced the crash(almost 100%) with a call trace similar to KaiyanM's report. After the patch, the bug no longer occurs even after millions of iterations.

CVSS Base Scores

version 3.1