CVE-2021-43267

What it actually does

CVE-2021-43267 is a remotely reachable heap-based buffer overflow in the Linux kernel TIPC implementation, specifically MSG_CRYPTO handling in net/tipc/crypto.c. The vulnerable code insufficiently validates attacker-controlled size fields when processing a TIPC crypto key message, allowing a malformed packet to overwrite kernel heap memory. On systems where TIPC is enabled and reachable, this can lead to remote kernel code execution, privilege escalation to kernel-level control, information disclosure, or system crash. The issue affects Linux kernels before 5.14.16 and was fixed upstream by commit fa40d9734a57bcbfa79a280189799f76c88f7bb0; many distributions may have backported the fix into older kernel version lines.

Why it matters to the business

Successful exploitation can give an unauthenticated remote attacker full control of an affected Linux host or cause outages through kernel crashes. Because this flaw is network exploitable with low complexity, has a critical CVSS score of 9.8, and public exploit material is available, exposed systems running TIPC should be treated as high-priority remediation targets even though the issue is not currently listed in the CISA KEV catalog. Compromise of kernel-level systems can affect service availability, data confidentiality, integrity of workloads, and trust in the host itself.

How an attack unfolds

An attacker first identifies a Linux system with TIPC enabled and reachable, commonly through UDP-based TIPC on port 6118 or native Ethernet TIPC traffic. They then send a crafted TIPC MSG_CRYPTO packet containing manipulated size fields. The vulnerable kernel path accepts the malformed values and copies more data than the destination buffer safely holds, corrupting kernel heap memory. Depending on kernel build, memory layout, hardening, and exploit reliability, the result may be a kernel panic or controlled memory corruption that allows execution of attacker-controlled code in kernel context. If code execution succeeds, the attacker can bypass normal user-space permissions, install persistence, disable security tooling, access sensitive data, pivot further, or use the host as infrastructure for additional attacks.

How to fix it

Upgrade affected Linux kernels to a fixed version. Upstream Linux is fixed in 5.14.16 and by commit fa40d9734a57bcbfa79a280189799f76c88f7bb0; use the relevant vendor-supported kernel package because distributions often backport the fix without changing to the upstream 5.14.16 version number. Reboot after kernel installation so the fixed kernel is actually running. If immediate patching is not possible, disable TIPC where it is not required: unload the tipc module, prevent it from loading at boot, and remove TIPC bearer configuration. Restrict network exposure by blocking inbound UDP port 6118 where UDP bearer is used and filtering native TIPC Ethernet traffic, including EtherType 0x88CA, at network boundaries where feasible. Treat network filtering as a temporary mitigation, not a substitute for patching, because local or adjacent network paths may still reach TIPC.

How to confirm the fix worked

Confirm the running kernel is fixed, not merely installed, by checking the active kernel version after reboot and validating vendor security advisories or package changelogs for the backport of the fix. For source-based builds, verify that commit fa40d9734a57bcbfa79a280189799f76c88f7bb0 or equivalent bounds-checking changes are present in net/tipc/crypto.c. Check whether TIPC is loaded with module inventory such as lsmod or /proc/modules, and check whether TIPC bearers are configured using the system's TIPC tooling. Validate network mitigation by confirming UDP/6118 is not reachable from untrusted networks and that native TIPC Ethernet frames are filtered where applicable. After remediation, monitor kernel logs for absence of TIPC-related crashes or memory corruption messages under normal traffic.

Typical attack path

1. Discover or infer that the target is running a vulnerable Linux kernel with TIPC support enabled.
2. Confirm that TIPC traffic can reach the host, such as UDP port 6118 or native TIPC Ethernet traffic.
3. Send a malformed TIPC MSG_CRYPTO message with attacker-controlled length fields.
4. Trigger heap memory corruption in the kernel TIPC crypto handling code.
5. Achieve kernel crash for denial of service or shape memory corruption toward kernel-level code execution.
6. If exploitation succeeds, establish privileged access, disable controls, collect data, or pivot to other systems.

How to detect it

To determine whether exploitation may have already occurred, review network telemetry, host logs, and crash artifacts. Network teams should search firewall, flow, packet capture, IDS, and Zeek-like logs for inbound or lateral TIPC traffic, especially UDP destination port 6118 or Ethernet traffic using TIPC EtherType 0x88CA, from unexpected sources. Packet-level inspection should focus on malformed or abnormal TIPC MSG_CRYPTO messages and unusual crypto key message sizes. Host teams should review kernel logs, system journal, dmesg history, vmcore/crash dumps, and EDR telemetry for kernel oops, panic, slab corruption, KASAN reports, or call traces referencing TIPC crypto functions. Also review audit and shell history for unexpected enabling of TIPC, such as loading the tipc module or configuring TIPC bearers shortly before suspicious traffic. Because reliable kernel exploitation may leave limited user-space evidence, unexplained crashes combined with unexpected TIPC traffic should be treated as suspicious. If kernel-level compromise is plausible, collect volatile evidence promptly, preserve crash dumps and logs, isolate the host, and perform a full compromise assessment.

• UDP/6118
• dst port 6118
• destination port 6118
• EtherType 0x88CA
• ethertype 0x88ca
• MSG_CRYPTO
• TIPC MSG_CRYPTO
• tipc_crypto_key_rcv
• tipc_crypto_msg_rcv
• net/tipc/crypto.c
• BUG: KASAN
• slab-out-of-bounds
• kernel BUG at net/tipc/crypto.c
• Oops:
• Kernel panic
• tipc:
• modprobe tipc
• insmod tipc
• tipc bearer enable
• /sys/module/tipc
• /proc/modules: tipc
• tipc.ko

What your security team should do

• Prioritize patching or mitigation for any Linux host where TIPC is enabled or where UDP/6118 or native TIPC Ethernet traffic is reachable from untrusted networks.
• Upgrade to a vendor-fixed kernel and reboot; verify the active running kernel contains the fix rather than relying only on installed package state.
• Disable and blacklist the TIPC kernel module on systems that do not explicitly require TIPC functionality.
• Block or tightly restrict UDP port 6118 and native TIPC Ethernet traffic, including EtherType 0x88CA, between trust zones.
• Hunt historical network telemetry for unexpected TIPC traffic, especially malformed or unusual MSG_CRYPTO activity and external sources contacting UDP/6118.
• Review kernel logs, crash dumps, and reboot history for unexplained panics or slab/KASAN memory corruption involving TIPC crypto code.
• If exploitation is suspected, treat the host as potentially kernel-compromised: preserve forensic evidence, isolate it, rotate secrets, and rebuild from trusted media after investigation.