Intel

CVE-2026-64352

Linux kernel (GCP) vulnerabilities

highEPSS 0.1 %

Beschreibung

Im Linux-Kernel wurde folgende Schwachstelle behoben: bpf: Erlauben des LPM-Map-Zugriffs von schlafberechtigten BPF-Programmen trie_lookup_elem() annotiert seine rcu_dereference_check()-Durchläufe nur mit rcu_read_lock_bh_held(). Da rcu_dereference_check(p, c) zu "c || rcu_read_lock_held()" wird, funktioniert dies für XDP/NAPI und klassische RCU-Leser, versagt jedoch bei schlafberechtigten BPF-Programmen, die über __bpf_prog_enter_sleepable() eintreten und nur rcu_read_lock_trace() halten. trie_update_elem() und trie_delete_elem() haben dasselbe Problem in anderer Form: Sie durchlaufen den Trie mit plain rcu_dereference(), das unbedingt rcu_read_lock_held() fordert. Beide sind über die Hilfsfunktionen bpf_map_update_elem / bpf_map_delete_elem von schlafberechtigten BPF-Programmen erreichbar und vom Syscall-Pfad unter klassischem rcu_read_lock(). Auf den Schreibwegen ist der Trie tatsächlich durch trie->lock (ein rqspinlock, der über den Durchlauf genommen wird) geschützt; wir haben uns dort nie auf das RCU-Lesersperre verlassen, um Knoten am Leben zu halten. Ein schlafberechtigter LSM-Hook, der einen LPM-Trie berührt, löst daher in Debug-Kernels lockdep aus: ============================= WARNUNG: verdächtige RCU-Nutzung 7.1.0-... Verunreinigt: G E ----------------------------- kernel/bpf/lpm_trie.c:249 verdächtige rcu_dereference_check()-Nutzung! 1 Sperre gehalten von net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, bei: __bpf_prog_enter_sleepable+0x26/0x280 Aufrufverfolgung: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 Dies betrifft nur lockdep – kein UAF, da Tasks Trace RCU gegen den Wiederherstellungs-Pfad des Tries serialisiert wird – aber es spammt die Konsole einmal pro einzigartigem Aufrufort auf jedem Debug-Kernel, der einen schlafberechtigten BPF LSM ausführt, der einen LPM-Trie berührt, was zunehmend häufiger vorkommt. Für den Lookup-Pfad wechseln Sie die rcu_dereference_check()-Annotation von rcu_read_lock_bh_held() zu bpf_rcu_lock_held(), das alle drei Kontexte (klassisch, BH, Tasks Trace) akzeptiert. Andere Kartentypen folgen bereits dieser Konvention. Für trie_update_elem() und trie_delete_elem() annotieren Sie die Durchläufe als rcu_dereference_protected(*p, 1) – passend zu trie_free() in der gleichen Datei – da trie->lock während des Durchlaufs gehalten wird. rqspinlock hat kein lockdep_map, sodass das Prädikat zu '1' degeneriert anstatt von lockdep_is_held(&trie->lock); die Schutzmaßnahme ist real, aber nicht maschinenverifizierbar. trie_get_next_key() verwendet ebenfalls plain rcu_dereference(), ist jedoch nur über den BPF-Syscall erreichbar, der klassisches rcu_read_lock() vor dem Weiterleiten hält, sodass es unberührt bleibt.

Quelle: UBUNTU_USNUBUNTU_USNUBUNTU_USNBSIBSI_CSAFDEBIAN_DSANVDCVELISTV5MSRC

Metriken

Severity
high
Priority-Score
231.31
KEV-Status
—
Exploit-Reife
kein öffentlicher PoC bekannt
XIEM Effective CVSS
7.8
Quelle: nvd-v3
CVSS v3
5.5
CVSS v4
—
EPSS-Perzentil
2.9 %
Niedrig — CVE gehört zu den unteren 10 % der heute bewerteten CVEs.
EPSS-Score
0.1 %
Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
Veröffentlicht
2026-09-07 09:05 UTC
CWE
—

Re-Analyse & Statuswechsel

Chronologie der NVD-Audit-Events für diese CVE — Reanalyses, CVSS-Updates, CPE-Diffs.

  1. CVE Modified2026-08-17 05:17 UTC· 416baaa9-dc9f-4396-8d5f-8c081fb06d67
    • Affected: Linux, Linux → Linux, Linux
  2. New CVE Received2026-07-25 10:17 UTC· 416baaa9-dc9f-4396-8d5f-8c081fb06d67
    • Affected: Linux, Linux
    • Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to "c || rcu_read_lock_held()", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched.
    • Reference: https://git.kernel.org/stable/c/2f884d371fafea137afea504d49ee4a7c8d7985b
    • Reference: https://git.kernel.org/stable/c/304ca50582f0c047370f85e13caec456f78c9fcc

Betroffene Betriebssysteme

  • linux

    redhat / enterprise_linux10.0

  • linux

    redhat / enterprise_linux7.0

  • linux

    redhat / enterprise_linux8.0

  • linux

    redhat / enterprise_linux9.0

  • linux

    ubuntu / linux-aws-6.8jammy

  • linux

    ubuntu / linux-azureresolute

  • linux

    ubuntu / linux-azuretrusty

  • linux

    ubuntu / linux-azurexenial

  • linux

    ubuntu / linux-azure-4.15bionic

  • linux

    ubuntu / linux-azure-5.4bionic

  • linux

    ubuntu / linux-azure-fdenoble

  • linux

    ubuntu / linux-azure-fderesolute

  • linux

    ubuntu / linux-azure-fde-6.8jammy

  • linux

    ubuntu / linux-azure-fipsbionic

  • linux

    ubuntu / linux-azure-fipsfocal

  • linux

    ubuntu / linux-azure-fipsnoble

  • linux

    ubuntu / linux-fipsjammy

  • linux

    ubuntu / linux-gcp-7.0noble

  • linux

    ubuntu / linux-gkejammy

  • linux

    ubuntu / linux-nvidia-tegranoble

  • linux

    ubuntu / linux-raspinoble

  • linux

    ubuntu / linux-raspi-realtimenoble

  • linux

    linux / linux_kernel2.6.12

  • linux

    linux / linux_kernel2.6.15

Quellen & Referenzen

Verknüpfte CVEs

1392 weitere CVEs anzeigen
IDCVE-2026-64352
Linux kernel (GCP) vulnerabilities — CVE-2026-64352 | NEOSEC Intel