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

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.