CVE-2026-23319

Description

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 Details

CVSS Score

7.8

Severity

HIGH

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Configurations (Affected Products)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE

Linux Kernel (Versions prior to fix commits in stable branches)

PoC / Exploit Code

⚠ For Security Research Only

The following code is for security research and authorized testing only.

python

// Conceptual reproduction logic based on the patch description
// This simulates the race condition in the Linux kernel BPF subsystem.

#include <linux/bpf.h>
#include <linux/delay.h>

void poc_trigger_race_condition(struct bpf_link *link) {
    // Thread 1: Initiates release
    // In the vulnerable version, cleanup of tr->progs_hlist is deferred.
    bpf_link_put(link);

    // Thread 2: Concurrent access (Exploitation Window)
    // This function attempts to use the link while it is being released.
    // If the refcount drops to zero but memory is not yet cleared, UAF occurs.
    bpf_trampoline_link_cgroup_shim(link);
}

// To reliably reproduce for testing (as per kernel dev notes):
// Insert 'msleep(100)' in bpf_shim_tramp_link_release before WARN_ON_ONCE.

References

[1] CVE.org https://www.cve.org/CVERecord?id=CVE-2026-23319
[2] NVD NIST https://nvd.nist.gov/vuln/detail/CVE-2026-23319
[3] CVE Details https://www.cvedetails.com/cve/CVE-2026-23319/
[4] VulDB https://vuldb.com/cve/CVE-2026-23319
[5] https://git.kernel.org/stable/c/3eeddb80191f7626ec1ef742bfff51ec3b0fa5c2
[6] https://git.kernel.org/stable/c/4e8a0005d633a4adc98e3b65d5080f93b90d356b
[7] https://git.kernel.org/stable/c/529e685e522b9d7fb379dbe6929dcdf520e34c8c
[8] https://git.kernel.org/stable/c/56145d237385ca0e7ca9ff7b226aaf2eb8ef368b
[9] https://git.kernel.org/stable/c/9b02c5c4147f8af8ed783c8deb5df927a55c3951
[10] https://git.kernel.org/stable/c/cfcfa0ca0212162aa472551266038e8fd6768cff

Raw JSON Data

JSON

{"cve": {"id": "CVE-2026-23319", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "published": "2026-03-25T11:16:28.570", "lastModified": "2026-04-23T21:05:38.103", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim\n\nThe root cause of this bug is that when 'bpf_link_put' reduces the\nrefcount of 'shim_link->link.link' to zero, the resource is considered\nreleased but may still be referenced via 'tr->progs_hlist' in\n'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in\n'bpf_shim_tramp_link_release' is deferred. During this window, another\nprocess can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'.\n\nBased on Martin KaFai Lau's suggestions, I have created a simple patch.\n\nTo fix this:\n Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'.\n Only increment the refcount if it is not already zero.\n\nTesting:\n I verified the fix by adding a delay in\n 'bpf_shim_tramp_link_release' to make the bug easier to trigger:\n\nstatic void bpf_shim_tramp_link_release(struct bpf_link *link)\n{\n\t/* ... */\n\tif (!shim_link->trampoline)\n\t\treturn;\n\n+\tmsleep(100);\n\tWARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link,\n\t\tshim_link->trampoline, NULL));\n\tbpf_trampoline_put(shim_link->trampoline);\n}\n\nBefore the patch, running a PoC easily reproduced the crash(almost 100%)\nwith a call trace similar to KaiyanM's report.\nAfter the patch, the bug no longer occurs even after millions of\niterations."}, {"lang": "es", "value": "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."}], "metrics": {"cvssMetricV31": [{"source": "[email protected]", "type": "Primary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "baseScore": 7.8, "baseSeverity": "HIGH", "attackVector": "LOCAL", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH"}, "exploitabilityScore": 1.8, "impactScore": 5.9}]}, "weaknesses": [{"source": "[email protected]", "type": "Primary", "description": [{"lang": "en", "value": "CWE-416"}]}], "configurations": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.0.1", "versionEndExcluding": "6.1.167", "matchCriteriaId": "72B24488-A57B-4D9C-A7EA-A6020518455B"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.2", "versionEndExcluding": "6.6.130", "matchCriteriaId": "C57BB918-DF28-46B3-94F7-144176841267"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.7", "versionEndExcluding": "6.12.77", "matchCriteriaId": "B3D12E00-E42D-4056-B354-BAD4903C03A5"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.13", "versionEndExcluding": "6.18.17", "matchCriteriaId": "A5E006E4-59C7-43C1-9231-62A72219F2BA"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.19", "versionEndExcluding": "6.19.7", "matchCriteriaId": "69245D10-0B71-485E-80C3-A64F077004D3"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:6.0:-:*:*:*:*:*:*", "mat ... (truncated)