CVE-2026-52993: Double-Free Vulnerability in Linux Kernel TIPC Module

The Transparent Inter-Process Communication (TIPC) module in the Linux kernel is designed for high-performance cluster communication. It operates as a network layer protocol, allowing nodes within a cluster to communicate efficiently over raw Ethernet, UDP, or other media. The attack surface is exposed directly to incoming network traffic when a TIPC bearer is configured and active, making it highly critical.

Within this framework, message fragmentation is handled by tipc_buf_append() in net/tipc/msg.c. This function is responsible for gathering incoming individual fragment buffers, tracking their sequence, and reassembling them into a coherent message structure before passing the completed buffer up the stack for validation.

The vulnerability, designated as CVE-2026-52993, is a critical double-free vulnerability (CWE-415) located within this reassembly process. It is rated with a CVSS v3.1 score of 9.8, indicating maximum severity. Unauthenticated remote attackers can exploit this flaw by sending specifically structured UDP or raw Ethernet frames, while local attackers can use it to achieve local privilege escalation.

The root cause of CVE-2026-52993 lies in how memory references are managed during the reassembly of fragmented messages. In tipc_buf_append(), the reassembled socket buffer head is tracked via a double pointer argument headbuf. A local pointer variable head is initialized to the value of *headbuf. When the final fragment (LAST_FRAGMENT) is processed, the function invokes tipc_msg_validate(&head) to verify the structure and headers of the newly reassembled packet.

Within tipc_msg_validate(), the kernel evaluates whether the socket buffer is using memory efficiently. If the buffer's physical footprint (truesize) is disproportionately large compared to its logical data length (len)—specifically if the ratio truesize / roundup_len(len) is equal to or greater than 4—the function reallocates a new, smaller buffer to prevent memory fragmentation. It then copies the existing data to the new buffer, deallocates the original socket buffer, and updates its local pointer argument to point to the new buffer.

Because tipc_buf_append() passes the address of its local variable head (&head) to tipc_msg_validate(), only the local variable head is updated when a reallocation occurs. The caller's tracking pointer, *headbuf, remains pointing to the old, deallocated socket buffer. If validation subsequently fails (for example, due to an invalid TIPC header version), tipc_buf_append() aborts and executes its error cleanup handler, calling kfree_skb(*headbuf). This causes the kernel to free the already-deallocated buffer a second time, triggering a double-free condition.

To understand the precise vulnerability mechanics, we must analyze the vulnerable code path in net/tipc/msg.c and compare it with the official patch. The following code block illustrates the vulnerability where the local variable is passed to the validation routine without updating the primary tracking pointer.

// Vulnerable Code Path
int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff **buf)
{
    // ...
    struct sk_buff *head = *headbuf; // Local copy of the caller's headbuf pointer
    // ...
    if (fragid == LAST_FRAGMENT) {
        TIPC_SKB_CB(head)->validated = 0;
        // The address of the local variable 'head' is passed here
        if (unlikely(!tipc_msg_validate(&head)))
            goto err; // Jumps to error cleanup without updating *headbuf
        // ...
    }
    // ...
err:
    kfree_skb(*buf);
    kfree_skb(*headbuf); // DOUBLE FREE: *headbuf still points to the old, freed skb
}

To address this issue, the patch introduces a check immediately following the validation failure. If the validation fails, the code determines whether the local head pointer has changed from the original *headbuf due to reallocation. If it has, *headbuf is updated with the new pointer value before jumping to the error label. This ensures that the cleanup routine deallocates the newly allocated buffer and does not reference the freed memory.

// Patched Code Path (Commit d293ca716e7d5dffdaecaf6b9b2f857a33dc3d3a)
int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff **buf)
{
    // ...
    struct sk_buff *head = *headbuf;
    // ...
    if (fragid == LAST_FRAGMENT) {
        TIPC_SKB_CB(head)->validated = 0;
        if (unlikely(!tipc_msg_validate(&head))) {
            // Propagate the new pointer back to the caller's reference if reallocated
            if (head != *headbuf)
                *headbuf = head;
            goto err;
        }
        // ...
    }
    // ...
}

This fix is complete because it guarantees that any reallocation within tipc_msg_validate() is synchronized with the caller's state tracking pointer, neutralizing the possibility of referencing a stale address during cleanup.

The exploitation of CVE-2026-52993 involves triggering the double-free condition to manipulate the SLUB allocator's metadata and gain control of kernel memory. An attacker can initiate this sequence either locally or remotely. The primary requirement is that the TIPC stack must be active and configured with a functional bearer.

In the first phase of the attack, the adversary establishes a TIPC link and floods the victim node with a precise sequence of tiny fragments. These small frames populate the page fragment lists, causing the truesize of the master socket buffer to grow linearly while its logical length remains low. This forces the ratio check to evaluate to true, triggering reallocation and deallocation of the initial buffer. By crafting the first fragment to contain an invalid TIPC version header, the attacker guarantees that validation will fail immediately after reallocation.

Once the double-free occurs, the SLUB allocator's freelist pointer is corrupted, typically resulting in a circular reference loop. The attacker can then reclaim this block by allocating structures such as files_struct or user_key_payload. By writing forged metadata over the overlapping memory, the attacker can redirect function pointers (such as f_op->flush) to kernel routines like override_creds or manipulate the user-space credentials directly, establishing full root privilege escalation.

The impact of CVE-2026-52993 is highly severe, threatening both system availability and integrity. Because the TIPC module can process incoming frames from raw Ethernet interfaces or UDP port 6118 without prior authentication, a remote attacker can exploit this flaw to cause immediate kernel panic and denial of service across cluster nodes.

On systems with local access, the vulnerability acts as a highly reliable mechanism for local privilege escalation. By abusing the overlapping slab allocations, an unprivileged user can hijack kernel-space execution flow. In environments where Supervisor Mode Access Prevention (SMAP) is disabled or not supported, this technique allows the kernel to execute structures pointing directly to user-controlled memory space, facilitating seamless privilege transition to uid 0.

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H reflects this danger. No user interaction or privileges are required to reach the vulnerable code path over the network, and the integrity, confidentiality, and availability impacts are all rated as high. This makes rapid remediation a priority for affected deployments.

Remediation requires updating the Linux kernel to a patched release. The fix has been backported to all major stable kernel branches, including 5.10.258, 5.15.209, 6.1.175, 6.6.141, 6.12.91, 6.18.33, and 7.0.10. Systems should be rebooted into a patched kernel version immediately.

If immediate patching is not possible, several temporary mitigations can be applied to block the exploit vectors. If the TIPC protocol is not actively required, the module should be blacklisted to prevent it from loading into memory. This can be configured by executing echo 'install tipc /bin/true' | sudo tee /etc/modprobe.d/tipc.conf and unloading any active instances using sudo rmmod tipc.

In environments where TIPC is necessary but remote exposure must be restricted, firewall rules should be configured to drop incoming packets on UDP port 6118 unless they originate from highly trusted, authenticated peer nodes. Additionally, restricting the creation of unprivileged user namespaces (sysctl -w kernel.unprivileged_userns_clone=0) can limit a local attacker's ability to configure the loopback interfaces and bearer channels required to execute the LPE exploit chain.