0.0
NA
CVE-2026-74609
tipc: read le->link under the node lock in tipc_node_link_down()
Description

In the Linux kernel, the following vulnerability has been resolved: tipc: read le->link under the node lock in tipc_node_link_down() tipc_node_link_down() caches the link pointer before taking n->lock: struct tipc_link *l = le->link; /* unlocked */ if (!l) return; tipc_node_write_lock(n); if (!tipc_link_is_establishing(l)) { /* deref l */ ... tipc_link_reset(l); /* write into l */ if (delete) { kfree(l); le->link = NULL; The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it: - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link supervision timer via tipc_node_timeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable() -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true) -> kfree(l). The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers disable_media() only schedules the asynchronous cleanup_bearer() work, so its synchronize_net() runs after the links are already gone. An in-flight CPU A that has read l therefore dereferences freed memory once B frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch. The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6: BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipc_link_is_establishing (net/tipc/link.c:285) tipc_node_link_down (net/tipc/node.c:1076) tipc_node_timeout (net/tipc/node.c:843) Allocated by task 9549: tipc_link_create (net/tipc/link.c:490) tipc_node_check_dest (net/tipc/node.c:1279) tipc_disc_rcv (net/tipc/discover.c:252) tipc_udp_recv (net/tipc/udp_media.c:389) Freed by task 9549: tipc_node_link_down (net/tipc/node.c:1084) tipc_node_delete_links (net/tipc/node.c:1320) bearer_disable (net/tipc/bearer.c:414) __tipc_nl_bearer_disable (net/tipc/bearer.c:992) Move the le->link read inside tipc_node_write_lock(), so it is serialised against the kfree() in the delete path. A racing teardown now either has not run yet, and we see a valid link, or has already run, and we see NULL.

INFO

Published Date :

Aug. 22, 2026, 4:16 p.m.

Last Modified :

Aug. 22, 2026, 4:16 p.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2026-74609 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel
Solution
Protect link pointer access by acquiring lock before reading. Update kernel to fix.
  • Acquire the node lock before reading the link pointer.
  • Update the Linux kernel to the latest version.
  • Apply the specific patch provided in the description.
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-74609 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-74609 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2026-74609 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2026-74609 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Aug. 22, 2026

    Action Type Old Value New Value
    Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '73f646cec35477b5099d7e952297cb9e1855be45', 'lessThan': '2be741ad565c610871a6a95062c12c39da7168fd', 'versionType': 'git'}, {'status': 'affected', 'version': '73f646cec35477b5099d7e952297cb9e1855be45', 'lessThan': '69d209461c110388710e483a130caf051e4fd09a', 'versionType': 'git'}, {'status': 'affected', 'version': '73f646cec35477b5099d7e952297cb9e1855be45', 'lessThan': 'de017c22135f545ca4e65d1eada22887b64958eb', 'versionType': 'git'}, {'status': 'affected', 'version': '73f646cec35477b5099d7e952297cb9e1855be45', 'lessThan': '47ba70891b10b2feb52462086b7fcd2ad75d3ce3', 'versionType': 'git'}, {'status': 'affected', 'version': '73f646cec35477b5099d7e952297cb9e1855be45', 'lessThan': 'a714d62513befef37f71f4ae89bb1fe173b65f2e', 'versionType': 'git'}, {'status': 'affected', 'version': '73f646cec35477b5099d7e952297cb9e1855be45', 'lessThan': 'c3f2347a47754eac690967cfd82cb6d559817b07', 'versionType': 'git'}, {'status': 'affected', 'version': '73f646cec35477b5099d7e952297cb9e1855be45', 'lessThan': '5558a8312452ddb21eff22b1cbd84302ad951944', 'versionType': 'git'}, {'status': 'affected', 'version': '73f646cec35477b5099d7e952297cb9e1855be45', 'lessThan': 'cba9ccb47e9fa4cc77692fb896cc5ab57a667882', 'versionType': 'git'}], 'programFiles': ['net/tipc/node.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '4.4'}, {'status': 'unaffected', 'version': '0', 'lessThan': '4.4', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '5.10.265', 'versionType': 'semver', 'lessThanOrEqual': '5.10.*'}, {'status': 'unaffected', 'version': '5.15.216', 'versionType': 'semver', 'lessThanOrEqual': '5.15.*'}, {'status': 'unaffected', 'version': '6.1.183', 'versionType': 'semver', 'lessThanOrEqual': '6.1.*'}, {'status': 'unaffected', 'version': '6.6.152', 'versionType': 'semver', 'lessThanOrEqual': '6.6.*'}, {'status': 'unaffected', 'version': '6.12.104', 'versionType': 'semver', 'lessThanOrEqual': '6.12.*'}, {'status': 'unaffected', 'version': '6.18.45', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '7.1.9', 'versionType': 'semver', 'lessThanOrEqual': '7.1.*'}, {'status': 'unaffected', 'version': '7.2', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['net/tipc/node.c'], 'defaultStatus': 'affected'}]
    Added Description In the Linux kernel, the following vulnerability has been resolved: tipc: read le->link under the node lock in tipc_node_link_down() tipc_node_link_down() caches the link pointer before taking n->lock: struct tipc_link *l = le->link; /* unlocked */ if (!l) return; tipc_node_write_lock(n); if (!tipc_link_is_establishing(l)) { /* deref l */ ... tipc_link_reset(l); /* write into l */ if (delete) { kfree(l); le->link = NULL; The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it: - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link supervision timer via tipc_node_timeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable() -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true) -> kfree(l). The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers disable_media() only schedules the asynchronous cleanup_bearer() work, so its synchronize_net() runs after the links are already gone. An in-flight CPU A that has read l therefore dereferences freed memory once B frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch. The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6: BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipc_link_is_establishing (net/tipc/link.c:285) tipc_node_link_down (net/tipc/node.c:1076) tipc_node_timeout (net/tipc/node.c:843) Allocated by task 9549: tipc_link_create (net/tipc/link.c:490) tipc_node_check_dest (net/tipc/node.c:1279) tipc_disc_rcv (net/tipc/discover.c:252) tipc_udp_recv (net/tipc/udp_media.c:389) Freed by task 9549: tipc_node_link_down (net/tipc/node.c:1084) tipc_node_delete_links (net/tipc/node.c:1320) bearer_disable (net/tipc/bearer.c:414) __tipc_nl_bearer_disable (net/tipc/bearer.c:992) Move the le->link read inside tipc_node_write_lock(), so it is serialised against the kfree() in the delete path. A racing teardown now either has not run yet, and we see a valid link, or has already run, and we see NULL.
    Added Reference https://git.kernel.org/stable/c/2be741ad565c610871a6a95062c12c39da7168fd
    Added Reference https://git.kernel.org/stable/c/47ba70891b10b2feb52462086b7fcd2ad75d3ce3
    Added Reference https://git.kernel.org/stable/c/5558a8312452ddb21eff22b1cbd84302ad951944
    Added Reference https://git.kernel.org/stable/c/69d209461c110388710e483a130caf051e4fd09a
    Added Reference https://git.kernel.org/stable/c/a714d62513befef37f71f4ae89bb1fe173b65f2e
    Added Reference https://git.kernel.org/stable/c/c3f2347a47754eac690967cfd82cb6d559817b07
    Added Reference https://git.kernel.org/stable/c/cba9ccb47e9fa4cc77692fb896cc5ab57a667882
    Added Reference https://git.kernel.org/stable/c/de017c22135f545ca4e65d1eada22887b64958eb
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.