Answer in brief
CVE-2026-43084 records a High severity (CVSS 7.8) vulnerability in netfilter: nfnetlink_queue: make hash table per queue. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=371de2bef6582a3f58049b3d18e190924af9c9a0 <22730cb96093b5be0609063bbb1923dbecd61252 || >=870e3e63da8e88daffe9d692a025c711658018a8 <41e3652a178cb0eecd48e0e6e27fbb73a004046a || >=70e2e3ce4f6841e12ec1c104fc76c0e707398ec4 <9e5ebef91120d2764aefe557c3a484b6288f341f || >=e19079adcd26a25d7d3e586b1837493361fdf8b6 <936206e3f6ff411581e615e930263d6f8b78df9d | 22730cb96093b5be0609063bbb1923dbecd61252, 41e3652a178cb0eecd48e0e6e27fbb73a004046a, 9e5ebef91120d2764aefe557c3a484b6288f341f, 936206e3f6ff411581e615e930263d6f8b78df9d |
| Linux/Linuxgeneric | >=6.12.75 <6.12.83 || >=6.18.14 <6.18.24 || >=6.19.4 <6.19.14 | 6.12.83, 6.18.24, 6.19.14 |
Published upstream
May 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 16, 2026
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: make hash table per queue Sharing a global hash table among all queues is tempting, but it can cause crash: BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue] [..] nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue] nfnetlink_rcv_msg+0x46a/0x930 kmem_cache_alloc_node_noprof+0x11e/0x450 struct nf_queue_entry is freed via kfree, but parallel cpu can still encounter such an nf_queue_entry when walking the list. Alternative fix is to free the nf_queue_entry via kfree_rcu() instead, but as we have to alloc/free for each skb this will cause more mem pressure.
Quoted source text, attributed separately from HOL analysis.