CVE-2022-0435

What it actually does

CVE-2022-0435 is a Linux kernel memory-corruption vulnerability in the TIPC protocol implementation. A malformed TIPC packet can declare more domain member nodes than the kernel’s fixed-size stack buffer supports, causing a stack overflow. If TIPC is enabled and reachable, an attacker with access to the TIPC network can crash the kernel and may be able to achieve kernel-level code execution or privilege escalation, resulting in full confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using or exposing Linux TIPC for clustering, virtualization, storage, or distributed application communication can be remotely disrupted and potentially fully compromised. Successful exploitation may cause host crashes, workload outages, service interruption, data exposure, or attacker control of affected servers. Although this issue is not currently listed in CISA KEV, exploit code is available and the EPSS score is high, so internet- or cluster-reachable TIPC deployments should be treated as urgent remediation targets.

How an attack unfolds

An attacker first identifies a Linux system where the TIPC kernel module is loaded and a TIPC bearer is active, such as Ethernet or UDP-based TIPC used for node-to-node communication. The attacker must be able to send traffic into that TIPC network or compromise a low-privileged foothold on a system that can reach it. They then craft a malformed TIPC protocol message whose domain member count exceeds the expected maximum of 64. When the vulnerable kernel processes the packet, it copies or interprets attacker-controlled data into a stack-allocated structure without adequate bounds enforcement, overflowing kernel stack memory. The most reliable outcome is a kernel crash or panic, causing denial of service. With sufficient exploit development, the overflow may be shaped to corrupt control data and execute code in kernel context, allowing privilege escalation or full host compromise.

How to fix it

Upgrade affected Linux kernels to a vendor-supported fixed release for the distribution and product in use. Because fixed versions vary by distribution and backport policy, use the security advisory or errata for the specific platform, including Red Hat Enterprise Linux, Fedora, oVirt, Red Hat Virtualization, and affected appliance firmware. If immediate patching is not possible, disable TIPC where it is not required, prevent the tipc kernel module from loading, and restrict TIPC traffic to trusted cluster networks only. Block unexpected TIPC UDP bearers and Layer 2 access paths with host firewalls, network ACLs, segmentation, and switch controls. Avoid exposing TIPC across untrusted networks. Reboot systems after kernel updates so the fixed kernel is actually running.

How to confirm the fix worked

Confirm that the running kernel version includes the vendor fix, not only that the package is installed. On Linux, compare `uname -r` with the distribution’s fixed advisory level and verify the host has been rebooted after patching. Check whether TIPC is loaded with `lsmod | grep '^tipc'` or by reviewing `/proc/modules`. Check for active TIPC configuration with `tipc bearer show`, `tipc node show`, and `ss -a | grep -i tipc` where the `tipc` utility is available. Validate that unneeded TIPC modules are blocked via modprobe configuration and that expected network controls prevent untrusted hosts from sending TIPC traffic. For UDP bearers, confirm firewall policy blocks unauthorized traffic to configured TIPC UDP ports. For Ethernet bearers, confirm only trusted nodes share the TIPC Layer 2 segment.

Typical attack path

1. Discover systems with TIPC enabled or infer TIPC exposure from cluster, virtualization, storage, or distributed application communications.
2. Gain network access to the TIPC bearer, such as the same Layer 2 segment, permitted UDP bearer path, or a compromised host inside the cluster network.
3. Craft a malformed TIPC packet containing an invalid domain member count greater than the supported limit of 64.
4. Send the malicious packet to the vulnerable Linux host over the active TIPC bearer.
5. Trigger kernel stack corruption while the TIPC message is processed.
6. Crash the host to cause denial of service, or attempt further exploitation to gain kernel-level execution or elevated privileges.
7. Use kernel-level access, if achieved, to disable defenses, access sensitive data, pivot, or maintain persistence.

How to detect it

Look for evidence of exploitation in kernel logs, system journals, crash dumps, and network telemetry around unexpected outages. Relevant log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `dmesg`, kdump/vmcore records, EDR kernel telemetry, firewall logs, and packet captures from cluster networks. Hunt for kernel oops, panic, stack corruption, general protection fault, or watchdog reset events where the call trace references TIPC functions such as `tipc_mon_rcv`, `tipc_rcv`, `tipc_udp_recv`, `tipc_link_proto_rcv`, `tipc_link_rcv`, or `tipc_msg_validate`. Investigate any crash shortly after unexpected TIPC traffic, TIPC bearer creation, or loading of the `tipc` module. For network detection, inspect cluster or UDP bearer traffic for malformed TIPC messages with abnormal domain member counts greater than 64 or unexpected TIPC traffic from non-cluster peers. Because exploitation may only leave a crash artifact, absence of a clear IOC does not prove the system was not attacked; preserve vmcore files and correlate timestamps with network flow data.

• /proc/modules: tipc
• lsmod: ^tipc\s
• journalctl -k: TIPC
• dmesg: TIPC
• tipc_mon_rcv
• tipc_rcv
• tipc_udp_recv
• tipc_link_proto_rcv
• tipc_link_rcv
• tipc_msg_validate
• BUG: kernel stack is corrupted
• Kernel panic - not syncing
• general protection fault
• Oops:
• Call Trace:
• stack-protector: Kernel stack is corrupted
• /var/crash
• /var/lib/systemd/coredump
• /proc/net/tipc
• tipc bearer show
• tipc node show

What your security team should do

• Prioritize patching or kernel upgrades on any system where TIPC is enabled, especially cluster, virtualization, storage, and appliance nodes.
• If TIPC is not explicitly required, disable it and block the kernel module from loading.
• Segment TIPC networks so only trusted cluster peers can send traffic to TIPC bearers.
• Hunt for prior crashes, kernel oops events, and panic traces referencing TIPC processing functions.
• Review asset inventory for Linux systems, Red Hat Enterprise Linux derivatives, Fedora, oVirt, Red Hat Virtualization hosts, and NetApp appliance firmware that may include vulnerable kernels.
• Treat exposed TIPC services as high risk because exploit code is available and the EPSS score indicates elevated likelihood of exploitation.
• After patching, verify the running kernel and reboot status rather than relying only on package inventory.
• Add monitoring for unexpected TIPC module loading or new TIPC bearer configuration.