Description
In the Linux kernel, the following vulnerability has been resolved:

tipc: serialize udp bearer replicast list updates

tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with
list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs
from the encap receive softirq (via tipc_udp_rcast_disc()) without
rtnl_lock(), so it can race the cleanup delete and corrupt the list:

list_del corruption. prev->next should be ffff8880298d7ab8,
but was ffff88802449ad38. (prev=ffff888027e3ec98)
kernel BUG at lib/list_debug.c:62!
RIP: __list_del_entry_valid_or_report+0x17a/0x200
Workqueue: events cleanup_bearer
Call Trace:
cleanup_bearer (net/tipc/udp_media.c:811)
process_one_work (kernel/workqueue.c:3302)
worker_thread (kernel/workqueue.c:3466)

The bearer can be enabled from an unprivileged user namespace, as the
TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM.

Add a spinlock to struct udp_bearer and take it around the list_add_rcu()
in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so
the two writers can no longer corrupt the list.

Reject a duplicate peer under the same lock before allocating, and remove
tipc_udp_is_known_peer(). The old lockless pre-check in
tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer
could both find it absent and add it twice.

cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the
bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add()
and add a peer after cleanup_bearer() has already emptied the list, leaking
that entry when the bearer is freed. Mark the bearer disabled under
rcast_lock once the list is emptied and refuse further additions.
Published: 2026-08-10
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw is a race condition in the Linux kernel's TIPC UDP bearer logic. Concurrent additions and deletions of peers are performed without proper serialization, which corrupts the replicast list and triggers a kernel BUG that crashes the system. The weakness is a classic concurrent execution race that can be exploited by an unprivileged user to cause a denial of service.

Affected Systems

The vulnerability resides in the Linux kernel, specifically within the tipc_udp_rcast_add() and cleanup_bearer() functions in net/tipc/udp_media.c. No explicit kernel version range is supplied, so any release lacking the patch may be affected. All installations that expose the TIPC UDP bearer through generic‑netlink in unprivileged user namespaces are potentially vulnerable.

Risk and Exploitability

The advisory does not publish a CVSS score and the EPSS score is unavailable, so a precise quantified risk cannot be given. The flaw can be triggered by an unprivileged user who can send generic‑netlink messages to the TIPCv2 interface. A successful race will result in a kernel panic and complete denial of service. The vulnerability is not listed in the CISA KEV catalog as a known exploited vulnerability.

Generated by OpenCVE AI on August 10, 2026 at 15:56 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that implements the patch adding a spinlock around the rcast list and removes the race with duplicate peer handling.
  • If an immediate kernel update is not possible, disable the TIPC UDP bearer feature by ensuring the bearer remains disabled in unprivileged user namespaces and preventing creation via netlink, thereby reducing the attack surface.
  • After applying the fix, monitor kernel logs for any ‘list_del corruption’ BUG messages to confirm the issue has been resolved.

Generated by OpenCVE AI on August 10, 2026 at 15:56 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 10 Aug 2026 12:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.
Title tipc: serialize udp bearer replicast list updates
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-10T12:02:59.034Z

Reserved: 2026-07-30T09:28:09.382Z

Link: CVE-2026-68323

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-10T21:45:03Z

Weaknesses

No weakness.