GHSA-P2WC-GRC5-CWHM

Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-25 12:31
VLAI
Details

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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64352"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-25T10:17:17Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Allow LPM map access from sleepable BPF programs\n\ntrie_lookup_elem() annotates its rcu_dereference_check() walks with\nonly rcu_read_lock_bh_held().  Because rcu_dereference_check(p, c)\nresolves to \"c || rcu_read_lock_held()\", this passes for XDP/NAPI and\nclassic RCU readers but fails for sleepable BPF programs, which enter\nvia __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace().\n\ntrie_update_elem() and trie_delete_elem() have the same problem in a\ndifferent form: they walk the trie with plain rcu_dereference(), which\nasserts rcu_read_lock_held() unconditionally.  Both are reachable from\nsleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem\nhelpers, and from the syscall path under classic rcu_read_lock().  In\nthe writer paths the trie is actually protected by trie-\u003elock (an\nrqspinlock taken across the walk); we never relied on the RCU read-side\nlock to keep nodes alive there.\n\nA sleepable LSM hook that ends up touching an LPM trie therefore\ntriggers lockdep on debug kernels:\n\n  =============================\n  WARNING: suspicious RCU usage\n  7.1.0-... Tainted: G            E\n  -----------------------------\n  kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage!\n  1 lock held by net_tests/540:\n   #0: (rcu_tasks_trace_srcu_struct){....}-{0:0},\n       at: __bpf_prog_enter_sleepable+0x26/0x280\n  Call Trace:\n   dump_stack_lvl\n   lockdep_rcu_suspicious\n   trie_lookup_elem\n   bpf_prog_..._enforce_security_socket_connect\n   bpf_trampoline_...\n   security_socket_connect\n   __sys_connect\n   do_syscall_64\n\nThis is lockdep-only -- no UAF, since Tasks Trace RCU does serialize\nagainst the trie\u0027s reclaim path -- but it spams the console once per\ndistinct callsite on every debug kernel running a sleepable BPF LSM\nthat touches an LPM trie, which is increasingly common.\n\nFor the lookup path, switch the rcu_dereference_check() annotation\nfrom rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all\nthree contexts (classic, BH, Tasks Trace).  Other map types already\nfollow this convention.\n\nFor trie_update_elem() and trie_delete_elem(), annotate the walks as\nrcu_dereference_protected(*p, 1) -- matching trie_free() in the same\nfile -- since trie-\u003elock is held across the walk.  rqspinlock has no\nlockdep_map, so the predicate degenerates to \u00271\u0027 rather than\nlockdep_is_held(\u0026trie-\u003elock); the protection is real but not\nmachine-verifiable.  trie_get_next_key() also uses bare\nrcu_dereference() but is reachable only from the BPF syscall, which\nholds classic rcu_read_lock() before dispatching, so it is left\nuntouched.",
  "id": "GHSA-p2wc-grc5-cwhm",
  "modified": "2026-07-25T12:31:32Z",
  "published": "2026-07-25T12:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64352"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f884d371fafea137afea504d49ee4a7c8d7985b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/304ca50582f0c047370f85e13caec456f78c9fcc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/57454944737f3ad9a8703aecbbb79713b513a94b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9bfdf4b81b0e56d47bc6c46c34a46638be716695"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bd6ad9a6b30498d845413e863fb95c6fab3babe3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ec662a8b2cde01e76b37ccd4b992d0342299e69c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f0967d4f1ba4323a3cb7dc8fdba74dd3a8caaf04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…