CVE-2026-80866
tipc: avoid busy looping in tipc_exit_net()
No known exploitation. EPSS puts it in the 9th percentile. Fixed versions are out.
No public exploit knownFix1 product4 fixed builds listed below
e.g. OID 1.3.6.1.4.1.25623.1.1.12.2026.8887.1
What to do
Find your product and version, then upgrade to the build on the right.
- LinuxAffected: ≥ 04c26faa51d1e2fe71cf13c45791f5174c37f986, < 772769859226a5b004442403510acb58a1c32e72Upgrade to: 772769859226a5b004442403510acb58a1c32e72Affected: ≥ 04c26faa51d1e2fe71cf13c45791f5174c37f986, < 99b82c8452887408ea908fdfa5df33c4a5dfa88fUpgrade to: 99b82c8452887408ea908fdfa5df33c4a5dfa88fAffected: ≥ 04c26faa51d1e2fe71cf13c45791f5174c37f986, < 110bb16d37bdba03213156c0df37e7119c190936Upgrade to: 110bb16d37bdba03213156c0df37e7119c190936Affected: ≥ 04c26faa51d1e2fe71cf13c45791f5174c37f986, < 7672973957e3e20780afe5937a9fec70b72bc060Upgrade to: 7672973957e3e20780afe5937a9fec70b72bc060 + 8 more branchesStated by: CVE record
Versions as the sources state them. Full version matrix after sign-in
What it is
From the CVE record
In the Linux kernel, the following vulnerability has been resolved: tipc: avoid busy looping in tipc_exit_net() Blamed commit introduced a busy-wait loop in tipc_exit_net() to wait for pending UDP bearer cleanup works to complete: while (atomic_read(&tn->wq_count)) cond_resched(); This loop can busy-wait for a long time if cond_resched() is a NOP. This typically happens if the netns exit is executed by a high priority task, or under kernels configured without preemption (CONFIG_PREEMPT_NONE). In such cases, it wastes CPU cycles and can lead to soft lockups. Fix this by replacing the busy loop with wait_var_event(), allowing the thread to sleep properly until the work queue count reaches zero. Accordingly, update cleanup_bearer() to use atomic_dec_and_test() and wake_up_var() to wake up the waiter when the count drops to zero. This uses the global wait queue hash table, avoiding the need to bloat struct tipc_net with a wait_queue_head_t. The atomic_dec_and_test() provides the necessary memory barrier to ensure the wakeup is not missed.
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.2% chance of exploitation activity in the next 30 days, which ranks it in the 9th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
6 events over 56 days, from the signal feeds we watch.
- Record updated
- OpenVAS check added
- Record updated
- Record updated
- Publishedrecord updated
Affected products
Sources
References in the record
- git.kernel.org/stable/c/772769859226a5b004442403510acb58a1c32e72
- git.kernel.org/stable/c/99b82c8452887408ea908fdfa5df33c4a5dfa88f
- git.kernel.org/stable/c/110bb16d37bdba03213156c0df37e7119c190936
And 3 more references. See all after sign-in
In the news
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Linux, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI