CVE-2026-68323

7.8 HIGH 0.1% exploit odds No fix listed Other OS & kernel

What it is

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.

At a glance

Exploitability: Can be exploited locally on the machine with a low-privilege account. High risk of data exposure, data tampering, service disruption.
Exploit odds: 0.1% chance of exploitation in the next 30 days (EPSS).
Fix: No patch or advisory is linked yet. Look at mitigations or restrict exposure.

Timeline

2026-07-30 09:28 UTC ReservedThe CVE id was reserved by its CNA
2026-08-10 13:20 UTC PublishedDisclosed publicly on CVE.org and NVD
2026-10-30 13:19 UTC Last updatedMost recent change to the record

Why it ranks here

Exploited in the wild: no, CISA does not list it.
Exploit odds: 0.1% in the next 30 days (EPSS).
Severity: 7.8 HIGH (CVSS).
Fix: none linked yet, which raises it.

Details

Published: 2026-08-10 13:20 UTC
Last modified: 2026-10-30 13:19 UTC
Exploit probability: 0.1% · EPSS, next 30 days
Weakness: CWE-362 · Race condition
Record status: Received

Attack profile CVSS 3.1 · 7.8

Attack vector: Local
Complexity: Low
Privileges needed: Low
User interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: High
Availability: High

Raw vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-68323.md and follow it. Check whether this project is affected by CVE-2026-68323. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

· More options · Status badge

Download Square Reddit

References

NVD record · CVE.org record