UBUNTU-CVE-2026-99246: Use After Free
In the Linux kernel, the following vulnerability has been resolved: tipc: protect node reset trace dump with node lock The tipcnoderesetlinks trace event asks tipcnodedump() to walk the node's link entries. Unlike the other node events that request link data, this event runs without the node lock. This permits bearer teardown to free a link while the trace callback is dumping it: CPU 0 CPU 1 tracetipcnoderesetlinks() tipcnodedump() l = n->links[0].link tipcnodewritelock() kfree(l) n->links[0].link = NULL tipcnodewriteunlock() tipclinkdump(l) tipclinkdump() then dereferences the stale pointer. KASAN reported: BUG: KASAN: slab-use-after-free in tipclinkdump Read of size 4 by task poc/115 Call Trace: tipclinkdump+0x10cb/0x16b0 tipcnodedump+0x4bb/0x740 traceeventraweventtipcnodeclass+0x258/0x360 tipcnoderesetlinks+0x14d/0x1a0 tipcrcv+0x13f5/0x3030 tipcudprecv+0x4e3/0x670 Allocated by task 0: tipclinkcreate+0x1e1/0x1020 tipcnodecheckdest+0x7d2/0x11a0 tipcdiscrcv+0xdbf/0x1430 Freed by task 89: kfree+0x131/0x3c0 tipcnodelinkdown+0x267/0x4b0 tipcnodedeletelinks+0xec/0x160 bearerdisable+0x107/0x260 Take the node write lock around the trace event. This serializes the dump against tipcnodelinkdown(delete=true), which frees the link under the same write lock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In tipc_node_reset_links(), take the node write lock around the tipc_node_reset_links trace event so the trace callback's tipc_node_dump() is serialized against tipc_node_link_down(delete=true) and cannot dereference a freed link.
Event History
Frequently Asked Questions
Which Ubuntu kernel packages are identified as affected?
The listed affected packages are ubuntu/linux-fips, ubuntu/linux, ubuntu/linux-aws, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-oracle, ubuntu/linux-aws-fips, and ubuntu/linux-azure-fips.
What condition triggers the use-after-free?
The issue requires a race between the TIPC node-reset trace event dumping a node's link entries and bearer teardown freeing one of those links. The trace path can then pass a stale link pointer to tipc_link_dump().
What is the observed impact of the race?
KASAN reported a slab use-after-free when tipc_link_dump() reads from the freed link object. The vulnerable path is associated with TIPC receive processing and bearer teardown.
What does the fix do?
The fix takes the node write lock around the node-reset trace dump, preventing bearer teardown from freeing a link while its data is being dumped.