CVE-2026-81008: interconnect: Fix use after free in icc_get() and of_icc_get_by_index()
In the Linux kernel, the following vulnerability has been resolved:
interconnect: Fix use after free in iccget() and oficcgetbyindex()
In oficcgetbyindex() and iccget(), 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, pathfind() calls pathinit(), which already links the path's requests into the reqlist of the respective interconnect nodes via hlistaddhead(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to iccget() or iccsetbw() 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 pathfind+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasanreport+0xac/0xfc pathfind+0x6f8/0xcfc iccget+0x148/0x380 iccgetset+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 iccget+0x2cc/0x380 iccgetset+0xf8/0x2d0
Fix this by replacing kfree(path) with the proper teardown function, iccput(path), which safely removes the requests from the reqlist using hlistdel() and drops the provider usage references before freeing the memory.
Additionally, in iccget(), ensure that the icclock mutex is released prior to calling iccput(path) to avoid a deadlock, as iccput() internally acquires the same lock.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the stale interconnect request entries?
A dynamic allocation for path->name must fail in icc_get() or of_icc_get_by_index(). The affected error path then frees the path object while its requests remain linked in interconnect nodes' req_list lists.
What operation can expose the resulting memory corruption after the allocation failure?
A later call to icc_get() or icc_set_bw() can traverse or modify the corrupted request lists and trigger a slab use-after-free. The reported reproduction used debugfs.
What does the available fix change?
The fix replaces the direct kfree(path) call in the allocation-failure path with icc_put(path). This performs the required teardown and removes the linked requests before freeing the path object.
What evidence may indicate this issue has been triggered?
The supplied report shows KASAN identifying a slab-use-after-free in path_find during an icc_get() call. The trace includes icc_get_set() and shows the object was freed earlier by the error path in icc_get().