The TIPC Titanic: Sinking the Linux Kernel with a Heap Overflow (CVE-2021-43267)

If you ask a random sysadmin what TIPC is, they'll probably look at you like you just asked them to recite the POSIX standard backwards. Transparent Inter-Process Communication (TIPC) is a protocol designed for efficient communication between nodes in a cluster. It's like TCP/IP's athletic cousin who does CrossFit and drinks raw eggs—optimized for speed and reliability within trusted environments.

But here's the kicker: TIPC is compiled into the vast majority of major Linux distro kernels by default. Even if you aren't using it, the code is there, lurking in the net/tipc/ directory, waiting for a module load. And in November 2021, we found out that this quiet, efficient protocol had a gaping hole in its crypto handling logic.

This vulnerability, CVE-2021-43267, isn't some complex race condition requiring millisecond precision. It's a logic error so fundamental it feels like a prank. It allows an attacker to send a specially crafted packet that tells the kernel, 'Hey, I have a small key, allocate a small buffer,' and then immediately says, 'Just kidding, here's a massive payload, copy it all in.' The kernel, ever the obedient servant, obliges, smashing through heap structures like a bull in a china shop.

The vulnerability lives in net/tipc/crypto.c, specifically in the function tipc_crypto_key_rcv. This function is responsible for receiving new encryption keys. When you design a secure protocol, you usually want to validate input before you act on it. In this case, the developers decided to embrace chaos.

The function receives a packet. The packet header tells the kernel how large the message is. The kernel uses this header size to allocate memory using kmalloc. So far, so good. If the header says 20 bytes, we get a 20-byte buffer.

However, the payload inside that packet contains the actual encryption key and a field specifying the key's length (keylen). The logic flaw is breathtakingly simple: the code copied the key data based on the payload's keylen into the buffer sized by the header's length. And the check to ensure keylen actually fits in the buffer? That happened after the memcpy.

It’s the architectural equivalent of letting a stranger into your house, watching them empty your fridge, smash your TV, and set fire to the curtains, and then checking their ID to see if they were on the guest list. By the time the check fails, the heap is already corrupted.

Let's look at the crime scene. The code below is a simplified view of what went wrong in tipc_crypto_key_rcv.

The Vulnerable Code

/* allocates memory based on the Message Header size */
skey = kmalloc(size, GFP_ATOMIC);
 
/* ... parses the packet to find the keylen inside the payload ... */
 
/* THE CRITICAL BUG: Copies 'keylen' bytes into 'skey->key' */
memcpy(skey->key, data + TIPC_AEAD_ALG_NAME, keylen);
 
/* Sanity check happens TOO LATE */
if (unlikely(size != keylen + sizeof(struct tipc_aead_key))) {
    kfree(skey);
    return -1;
}

As you can see, the memcpy executes blindly. If size (from the header) is small, but keylen (from the body) is large, we write past the end of skey. This is a classic heap overflow.

The Fix

The patch (Commit fa40d9734a57bcbfa79a280189799f76c88f7bb0) is straightforward: move the validation logic before the allocation and copy.

/* New Validation Logic */
keylen = ntohl(*((__be32 *)(data + TIPC_AEAD_ALG_NAME)));
 
/* Check sizes BEFORE doing anything dangerous */
if (unlikely(size != keylen + sizeof(struct tipc_aead_key) ||
             keylen > TIPC_AEAD_KEY_SIZE_MAX)) {
    return -1;
}
 
skey = kmalloc(size, GFP_ATOMIC);
memcpy(skey->key, data + TIPC_AEAD_ALG_NAME, keylen);

The fix also enforces TIPC_AEAD_KEY_SIZE_MAX, ensuring that even if the header size matches the key length, the key length itself isn't absurdly large.

This isn't just a crash; it's a reliable path to root. Exploiting Linux kernel heap overflows in 2021 required bypassing KASLR (Kernel Address Space Layout Randomization) and finding a way to hijack control flow. The exploit strategy developed by researchers (like bl4sty) is a masterclass in heap grooming.

Phase 1: Heap Spraying with msg_msg

To exploit this, we need to control what sits next to our vulnerable object in memory. Attackers use the msg_msg struct (related to System V IPC messages) because it's an "elastic" object—we can control its size and data. We spray thousands of these objects to fill the heap, creating a predictable pattern.

Phase 2: The Leak (KASLR Bypass)

We trigger the vulnerability to overflow into an adjacent msg_msg object. Specifically, we overwrite the m_ts (message text size) field. If we change a message size from 64 bytes to 4096 bytes, and then ask the kernel to read that message back to us, it will read 4096 bytes—way past the original message end. This Out-Of-Bounds (OOB) read leaks kernel pointers from adjacent objects, revealing the KASLR slide.

Phase 3: Control Flow Hijacking

With the address map in hand, we attack again. This time, we target a structure that contains function pointers, such as tty_struct. By overwriting the ops pointer in a tty_struct to point to a fake table we control, we can redirect execution.

Phase 4: The modprobe_path Trick

Instead of fighting ROP chains, a modern lazy approach is to overwrite modprobe_path. This global kernel variable contains the path to the program executed when the kernel needs to load a module (usually /sbin/modprobe). If we overwrite this string to point to /tmp/x (a script we control), and then trigger a module load (by trying to open a file with a dummy format), the kernel executes our script as root. Game over.

The impact here is binary: you are either fine, or you are completely owned.

Remote Execution: If you have TIPC configured on a bearer (like Ethernet or UDP) and port 6118 is exposed to the internet, this is a Remote Code Execution (RCE) vulnerability. An unauthenticated attacker can send a single UDP packet and get a root shell. This is the worst-case scenario.

Local Privilege Escalation: Even if you don't use TIPC for networking, the module can often be loaded by a local user via Netlink sockets. This means any user on the box can trigger the vulnerability to escalate privileges from nobody to root.

The EPSS score sits at a terrifying 72.6%, meaning this is actively being targeted. It's stable, it's reliable, and it affects a massive range of kernel versions (4.8 through 5.14.15).

The obvious fix is to patch. You need to be on Linux Kernel 5.14.16 or later. If you are running an LTS kernel, check your distro's backports immediately.

However, in the real world, you can't always reboot the production database server instantly. If you cannot patch, you must neutralize the attack surface.

1. Blacklist the Module If you don't use TIPC, kill it. This prevents the vulnerable code from ever loading.

# Create a blacklist file
echo "install tipc /bin/true" | sudo tee /etc/modprobe.d/disable-tipc.conf
 
# Unload the module if it's currently running
sudo rmmod tipc

2. Network Defense If you must use TIPC, ensure that UDP port 6118 is strictly firewalled. It should never, ever be exposed to the public internet. It should only accept traffic from trusted cluster nodes.