PT-2026-90138 · Linux · Linux
CVE-2026-81008
·
Published
2026-09-11
·
Updated
2026-09-11
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux