bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.15.209, 6.1.175, 6.6.141, 6.12.91, 6.18.33, and 1 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From e624d4ed4aa8cc3c69d1359b0aaea539203ed266 · fixed in 4a3d0fe30b907ff324b1b49756f7e713d67f3645; From e624d4ed4aa8cc3c69d1359b0aaea539203ed266 · fixed in b089aa6e94d7a08e74d076a0fe274842dc9feccc; From e624d4ed4aa8cc3c69d1359b0aaea539203ed266 · fixed in 571a05ea1baaccc0dc1e0d227b2cbc978b96d392; From e624d4ed4aa8cc3c69d1359b0aaea539203ed266 · fixed in cb2c1f3cf65b855548e1b8d55a08bfbaa5a0901a; From e624d4ed4aa8cc3c69d1359b0aaea539203ed266 · fixed in d4c4bd231ebad70e6f30db429e9640bf378b2f52; From e624d4ed4aa8cc3c69d1359b0aaea539203ed266 · fixed in 7027e705062482a8cea43a1c13ede3c35653966f; From e624d4ed4aa8cc3c69d1359b0aaea539203ed266 · fixed in 8ed82f807bb09d2c8455aaa665f2c6cb17bc6a19
- Linux Linux
5.14
- KernelLinux
From 5.14.0 · fixed in 5.15.209; From 5.16.0 · fixed in 6.1.175; From 6.2.0 · fixed in 6.6.141; From 6.7.0 · fixed in 6.12.91; From 6.13.0 · fixed in 6.18.33; From 6.19.0 · fixed in 7.0.10
References 7
git.kernel.org
- stable/c/4a3d0fe30b907ff324b1b49756f7e713d67f3645
- stable/c/b089aa6e94d7a08e74d076a0fe274842dc9feccc
- stable/c/571a05ea1baaccc0dc1e0d227b2cbc978b96d392
- stable/c/cb2c1f3cf65b855548e1b8d55a08bfbaa5a0901a
- stable/c/d4c4bd231ebad70e6f30db429e9640bf378b2f52
- stable/c/7027e705062482a8cea43a1c13ede3c35653966f
- stable/c/8ed82f807bb09d2c8455aaa665f2c6cb17bc6a19