Skip to main content
VulnerabilityPublished Updated

CVE-2026-68323: Linux kernel · tipc: serialize udp bearer replicast list updates

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in d70c81001df9320d3445e664428a1d408b5ba896 : patch Linux kernel soon.

Data as of 26 Oct 2026, 14:05 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 0% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in d70c81001df9320d3445e664428a1d408b5ba896, 350e592ff4e30e48ffb55e142d11a73e63f4869c, 5d3cea7d41dc72073fea6f879815c9b57c3b330d +2
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ ef20cd4dd1633987bcf46ac34ace2c8af212361f, < d70c81001df9320d3445e664428a1d408b5ba896
Fixed in
  • d70c81001df9320d3445e664428a1d408b5ba896
LinuxLinuxAffected
  • ≥ ef20cd4dd1633987bcf46ac34ace2c8af212361f, < 350e592ff4e30e48ffb55e142d11a73e63f4869c
Fixed in
  • 350e592ff4e30e48ffb55e142d11a73e63f4869c
LinuxLinuxAffected
  • ≥ ef20cd4dd1633987bcf46ac34ace2c8af212361f, < 5d3cea7d41dc72073fea6f879815c9b57c3b330d
Fixed in
  • 5d3cea7d41dc72073fea6f879815c9b57c3b330d
LinuxLinuxAffected
  • ≥ ef20cd4dd1633987bcf46ac34ace2c8af212361f, < 3ff143a884a19bfcf3aebd999b02274fe44f46f3
Fixed in
  • 3ff143a884a19bfcf3aebd999b02274fe44f46f3
LinuxLinuxAffected
  • ≥ ef20cd4dd1633987bcf46ac34ace2c8af212361f, < 3ff6b534d20824cddab99c81ea3bd1144e635626
Fixed in
  • 3ff6b534d20824cddab99c81ea3bd1144e635626
LinuxLinuxAffected
  • =4.9
Fixed in–

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.

References

Community reviews

Loading reviews…