Cloudanix VulnDB

CVE-2026-68323

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's networking code can let a local user trigger a crash by racing two internal operations that manage a list of network peers.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition between tipc_udp_rcast_add() and cleanup_bearer() performing unsynchronized list_add_rcu/list_del_rcu operations on udp_bearer->rcast.list, allowing list corruption, duplicate entries, and use-after-free when the bearer is enabled from an unprivileged user namespace.

Why it matters to the business

Linux systems using TIPC over UDP can experience kernel panics and denial of service, disrupting networked applications that rely on the protocol.

How an attack unfolds

An attacker in an unprivileged user namespace enables a TIPC UDP bearer via generic netlink, then triggers concurrent encap receive softirq activity and bearer cleanup workqueue execution; the missing spinlock permits the add and delete paths to interleave, corrupting the RCU list and crashing the kernel.

How to fix it

Apply the upstream fix that adds a spinlock (rcast_lock) around list operations in tipc_udp_rcast_add and cleanup_bearer, rejects duplicates under the lock, and marks the bearer disabled once the list is emptied.

How to confirm the fix worked

Confirm the presence of the spinlock and disabled-bit checks in net/tipc/udp_media.c; test by repeatedly enabling/disabling UDP bearers from user namespaces while generating encap traffic and verify absence of list corruption BUGs.

Typical attack path

  1. Create or join an unprivileged user namespace
  2. Use TIPC generic netlink commands to enable a UDP bearer without GENL_ADMIN_PERM
  3. Trigger encap receive paths that call tipc_udp_rcast_disc and tipc_udp_rcast_add
  4. Force bearer disable/cleanup_bearer via tipc_udp_disable while softirqs are still active
  5. Race the list updates to induce list_del corruption and kernel BUG

How to detect it

Search kernel logs for 'list_del corruption' messages referencing lib/list_debug.c or workqueue cleanup_bearer; inspect for repeated TIPC UDP bearer enable/disable sequences from user namespaces in audit or netlink traces.

What your security team should do

  • Prioritize kernel updates containing the rcast_lock serialization for any system exposing TIPC UDP bearers
  • Restrict unprivileged user namespace creation or TIPC netlink access via LSM or seccomp policies until patched
  • Monitor for TIPC-related kernel oops in system logs on unpatched hosts

The record

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.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities