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

CVE-2026-81008

Affected Products

Linux