UBUNTU-CVE-2026-80866: Medium severity ubuntu/linux-aws vulnerability
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Compensating control
In tipc_exit_net(), replace the busy-wait loop that checks tn->wq_count with wait_var_event() so the thread sleeps until the work queue count reaches zero; update cleanup_bearer() to use atomic_dec_and_test() and call wake_up_var() when the count drops to zero.
Event History
Frequently Asked Questions
Which systems are most likely to experience this issue?
Systems using the affected Ubuntu kernel packages are exposed when a TIPC network namespace exits while UDP bearer cleanup work is still pending. The busy loop is most problematic when namespace exit runs in a high-priority task or on kernels built with CONFIG_PREEMPT_NONE, where cond_resched() may not yield.
What impact can exploitation or triggering have?
The condition can waste CPU cycles for an extended period and lead to soft lockups while tipc_exit_net() waits for pending UDP bearer cleanup. The supplied vector indicates local access and low privileges are required, with availability as the affected impact.
What needs to happen to trigger the problem?
A local low-privileged actor needs to cause TIPC network namespace teardown while pending UDP bearer cleanup work remains. The issue does not require user interaction according to the supplied vector.
What change addresses the issue?
The fix replaces the polling loop with wait_var_event(), allowing the exiting thread to sleep until the pending work count reaches zero. Cleanup now decrements the count with atomic_dec_and_test() and wakes the waiter with wake_up_var().