CVE-2026-80866: tipc: avoid busy looping in tipc_exit_net()
In the Linux kernel, the following vulnerability has been resolved:
tipc: avoid busy looping in tipcexitnet()
Blamed commit introduced a busy-wait loop in tipcexitnet() to wait for pending UDP bearer cleanup works to complete:
while (atomicread(&tn->wqcount)) condresched();
This loop can busy-wait for a long time if condresched() is a NOP. This typically happens if the netns exit is executed by a high priority task, or under kernels configured without preemption (CONFIGPREEMPTNONE). In such cases, it wastes CPU cycles and can lead to soft lockups.
Fix this by replacing the busy loop with waitvarevent(), allowing the thread to sleep properly until the work queue count reaches zero.
Accordingly, update cleanupbearer() to use atomicdecandtest() and wakeupvar() 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 tipcnet with a waitqueueheadt. The atomicdecandtest() provides the necessary memory barrier to ensure the wakeup is not missed.
Affected Software
Event History
Frequently Asked Questions
Under what conditions is the problem most likely to occur?
It can occur during network-namespace exit while UDP bearer cleanup work is still pending. It is most likely when the exit runs in a high-priority task or on kernels built with CONFIG_PREEMPT_NONE, where cond_resched() may not yield.
What is the practical impact on an affected system?
The namespace-exit path can consume CPU in a prolonged busy-wait while waiting for cleanup work to finish. This can waste CPU cycles and potentially cause soft lockups.
What behavior indicates that a system may be affected?
Relevant symptoms are high CPU use or soft-lockup reports associated with network-namespace teardown when pending TIPC UDP bearer cleanup work exists. The provided information does not identify a more specific detection method.