HIGH Introduced in 5.6
interconnect Path UAF
CVE-2026-81008
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.0HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.
02KernelScan AI Analysis
Risk summary
A use-after-free in the Linux interconnect framework occurs when a memory allocation failure during path setup causes improper cleanup, leaving dangling list pointers in interconnect node request lists. A local attacker who can trigger memory pressure and subsequent interconnect operations can exploit this to corrupt kernel heap memory, potentially achieving code execution or causing a kernel crash. Products on SoC platforms with interconnect providers configured are affected.
Vulnerability analysis
When the interconnect framework sets up a path between two nodes, it links the path's bandwidth requests into each node's request list before allocating a name string for the path. If that name allocation fails under memory pressure, the error path frees the path object directly without unlinking those requests, leaving dangling pointers in the node lists. The next interconnect operation that traverses or modifies those lists hits freed memory, producing a slab use-after-free. The fix replaces the direct free with the proper teardown routine, which removes each request from its node list and drops provider references before releasing the path object; it also releases the interconnect mutex first to avoid a self-deadlock. The vulnerable code is reachable from local processes that trigger driver operations invoking the interconnect API, and the OOM condition that starts the bug can be induced by any local user through memory pressure.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 5.6 | 5.10.270 | 03c3af594dea |
| mainline | 5.6 | 7.3-rc1 | 25c7e242aca0 |
| 6.1 | 5.6 | 6.1.188 | 9a671125d422 |
| 6.12 | 5.6 | 6.12.109 | a4e9aa7907ad |
| 5.15 | 5.6 | 5.15.221 | d4d73decdb9a |
| 7.2 | 5.6 | 7.2.4 | d715d19cfcfe |
| 6.6 | 5.6 | 6.6.157 | fedea72e8f31 |
| 6.18 | 5.6 | 6.18.50 | db8147c5d5ad |
| cip/6.12 | 5.6 | 6.12.111-cip32 | a4e9aa7907ad |