tipc: hold a reference to nodes found by link name

Overview

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

tipc: hold a reference to nodes found by link name

tipc_node_find_by_name() returns a node after dropping its RCU read lock without taking a reference. The LINK_SET, LINK_GET and LINK_RESET_STATS handlers then lock and access the node, racing with timer-driven cleanup of a down peer. Generic netlink serialization does not exclude the node timer.

The following interleaving can leave a handler using a freed node:

CPU 0: find the node under RCU and release the node read lock CPU 1: tipc_node_timeout() clears the links and unlinks the down node CPU 1: drop the list and timer references, queuing tipc_node_free() CPU 0: leave the RCU read-side critical section CPU 1: complete the grace period and free the node CPU 0: acquire the node lock through the stale pointer

LINK_SET also uses the node's media address after releasing the node lock, when passing queued packets to tipc_bearer_xmit().

KASAN on v7.3-rc5 reported:

BUG: KASAN: slab-use-after-free in _raw_read_lock_bh Write of size 4 at addr ffff88807e06f008 by task poc/92 Call Trace: _raw_read_lock_bh kernel/locking/spinlock.c:287 tipc_nl_node_set_link net/tipc/node.c:2475 genl_family_rcv_msg_doit net/netlink/genetlink.c:1114 genl_rcv_msg net/netlink/genetlink.c:1209 netlink_rcv_skb net/netlink/af_netlink.c:2575

Allocated by task 0: tipc_node_create net/tipc/node.c:539 tipc_node_check_dest net/tipc/node.c:1196 tipc_disc_rcv net/tipc/discover.c:252

Freed by task 92: kfree mm/slub.c:6801 rcu_core kernel/rcu/tree.c:2919

Last potentially related work creation: __call_rcu_common.constprop.0 kernel/rcu/tree.c:3181 tipc_node_timeout net/tipc/node.c:814

Acquire a reference to the selected node with kref_get_unless_zero() before leaving RCU, returning NULL if the node has already been released. Release that reference on every caller exit after the last node access, including transmission in LINK_SET. Keep the existing link lookup order and locking so concurrent link removal still takes the existing error paths.

Affected

• Linux >= 6a939f365bdb03a74b4617bdb4402fc08da088b9 < b60259d4047fbb735476c729dcf9306a038b6110
• Linux >= 6a939f365bdb03a74b4617bdb4402fc08da088b9 < f17e70206a1e763fcca2578a8db3c4eed0f843a9
• Linux >= 6a939f365bdb03a74b4617bdb4402fc08da088b9 < 1428c5f1d346a2e1ac9156713975a72246957009
• Linux >= 6a939f365bdb03a74b4617bdb4402fc08da088b9 < 3c3b308ee6e25729a6cf09b69cdd0e093220d40b
• Linux >= 6a939f365bdb03a74b4617bdb4402fc08da088b9 < 17e73bae400f6a434dc006e3bee92c94cf781954
• Linux 4.19

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.