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.

En el núcleo de Linux, se ha solucionado la siguiente vulnerabilidad: bpf: Corrección de un problema de UAF en bpf_trampoline_link_cgroup_shim. La causa principal de este error es que, cuando «bpf_link_put» reduce a cero el contador de referencias de «shim_link->link.link», el recurso se considera liberado, pero aún puede ser referenciado a través de «tr->progs_hlist» en «cgroup_shim_find». La limpieza real de «tr->progs_hlist» en «bpf_shim_tramp_link_release» se aplaza. Durante este intervalo, otro proceso puede provocar un uso después de la liberación a través de «bpf_trampoline_link_cgroup_shim». Basándome en las sugerencias de Martin KaFai Lau, he creado un parche sencillo. Para solucionar esto: añadir una comprobación atómica de que no sea cero en «bpf_trampoline_link_cgroup_shim». Solo incrementar el contador de referencias si aún no es cero. Pruebas: He verificado la corrección añadiendo un retraso en «bpf_shim_tramp_link_release» para que el error sea más fácil de provocar: 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); } Antes del parche, al ejecutar un PoC se reproducía fácilmente el bloqueo (casi al 100 %) con un seguimiento de llamadas similar al del informe de KaiyanM. Tras el parche, el error ya no se produce ni siquiera tras millones de iteraciones.