UBUNTU-CVE-2026-68323: High severity ubuntu/linux-azure vulnerability
In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipcudprcastadd() and cleanupbearer() both update ub->rcast.list with listaddrcu() / listdelrcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipcudprcastdisc()) without rtnllock(), so it can race the cleanup delete and corrupt the list: listdel corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/listdebug.c:62! RIP: listdelentryvalidorreport+0x17a/0x200 Workqueue: events cleanupbearer Call Trace: cleanupbearer (net/tipc/udpmedia.c:811) processonework (kernel/workqueue.c:3302) workerthread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENLADMINPERM. Add a spinlock to struct udpbearer and take it around the listaddrcu() in tipcudprcastadd() and the listdelrcu() loop in cleanupbearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipcudpisknownpeer(). The old lockless pre-check in tipcudprcastdisc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanupbearer() runs from a workqueue after tipcudpdisable() clears the bearer's up bit, so an encap softirq can still reach tipcudprcastadd() and add a peer after cleanupbearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcastlock once the list is emptied and refuse further additions.
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-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1036.39 - 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
Add a spinlock to struct udp_bearer and hold it around list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() to serialize updates to ub->rcast.list.
- Compensating control
Under rcast_lock, mark the bearer disabled once ub->rcast.list is emptied, and make tipc_udp_rcast_add() refuse further peer additions for the disabled bearer.
- Compensating control
Under the same lock, reject a duplicate peer before allocating it; remove the racy tipc_udp_is_known_peer() pre-check.
Event History
Frequently Asked Questions
Who can trigger this issue?
A local low-privileged attacker can enable the affected bearer from an unprivileged user namespace because the TIPCv2 generic-netlink operations do not require GENL_ADMIN_PERM. The vulnerable update path runs from the encapsulation receive softirq and can race bearer cleanup.
Is a default configuration known to be affected?
The available information does not state whether the TIPC UDP bearer is enabled by default. Exposure depends on whether the affected bearer can be enabled and exercised on the system.
What evidence may indicate that a system has encountered this vulnerability?
The reported failure is list corruption followed by a kernel BUG in lib/list_debug.c, specifically __list_del_entry_valid_or_report. The trace may show cleanup_bearer running on the events workqueue, with the affected code in net/tipc/udp_media.c.