CVE-2026-80866

tipc: avoid busy looping in tipc_exit_net()

N/A
Published: September 4, 2026 at 04:48 PM UTC
Updated: October 21, 2026 at 01:20 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

04c26faa51d1e2fe71cf13c45791f5174c37f9864c26faa51d1e2fe71cf13c45791f5174c37f9865.10.425.12.95.135.4.1245195ec5e365a2a9331bfeb585b613a6e94f98dbab9f5b7ad4ac3af006443f535b1ce7bff1d130d7dd1f76dfadaf8f47ed1753f97dbcbd41c16215ffa
Vendor states this is fixed in 522d1d950b9e3b68190a6de7534827c8dccedb73 (fixed)
Vendor states this is fixed in c1481c94e74c955e0448ddf46b8615a44d840c1e (fixed)
Affected range stops below 5.11, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.13 (unaffected)
Affected range stops below 5.5, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.12.114 (unaffected)
Vendor states this is fixed in 6.18.57 (unaffected)
Vendor states this is fixed in 6.6.160 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card