CVE-2026-64450

What it actually does

This is an out-of-bounds read in the Linux kernel TIPC subsystem when processing broadcast PROTOCOL/STATE_MSG Gap ACK blocks. The vulnerable broadcast receive path validates that the Gap ACK record length is internally consistent with its count fields, but fails to verify that the record actually fits inside the received message data area. A malicious TIPC peer can craft a short broadcast STATE_MSG containing a Gap ACK record with attacker-controlled counts, causing the kernel to copy more bytes from the socket buffer than were actually present. This can trigger a kernel memory over-read, kernel crash/panic, and potentially disclosure of adjacent kernel memory contents depending on runtime configuration and how copied data is later consumed.

Why it matters to the business

Systems using the Linux kernel TIPC protocol may be exposed to remote kernel-level denial of service and possible sensitive memory exposure from network-reachable attackers able to send crafted TIPC traffic. The CVSS score is critical at 9.1 because exploitation requires no authentication, no user interaction, and low attack complexity once TIPC is reachable. Although EPSS is currently low and the issue is not listed in CISA KEV, kernel network flaws should be prioritized in clustered, telecom, high-availability, container-host, and infrastructure environments where TIPC may be enabled or reachable.

How an attack unfolds

An attacker first gains network reachability to a host or cluster using TIPC and behaves as, or reaches, a TIPC neighbor capable of sending broadcast protocol messages. The attacker then sends an ordinary broadcast STATE_MSG that passes basic broadcast ACK validation and includes a malformed Gap ACK block. The Gap ACK block is crafted so its length field appears consistent with its ugack_cnt and bgack_cnt values, for example a large bgack_cnt with a short actual message data area. In the vulnerable broadcast path, the kernel accepts the record without checking it against the real message payload size. When the message is processed, tipc_link_advance_transmq() calls kmemdup() using the attacker-controlled count-derived size, reading beyond the end of the received skb buffer. The immediate result may be a KASAN-detected slab out-of-bounds read, kernel warning, crash, or panic; on systems without hardening, adjacent kernel memory may be copied into internal structures and potentially influence later processing or expose information.

How to fix it

Apply the Linux kernel update or distribution vendor security update that includes the TIPC broadcast Gap ACK bounds-check fix. Because no exact package fixed versions were provided, use the relevant vendor advisory for the deployed distribution or kernel branch and confirm the patch adds validation in the broadcast path so Gap ACK records are checked against msg_data_sz() before processing. If immediate patching is not possible, disable TIPC where it is not required, unload or block the tipc kernel module if operationally safe, and restrict TIPC traffic to trusted cluster networks only. Enforce host and network firewall controls to block unsolicited TIPC transport traffic, including UDP port 6118 where UDP bearer is used, and limit L2 TIPC exposure to trusted segments. Reboot into the patched kernel after updating; merely installing kernel packages is not sufficient until the running kernel is replaced.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix, not just that an updated package is installed. Validate with uname -a, package manager kernel inventory, and vendor advisory mapping for the exact distribution/kernel stream. Check whether TIPC is in use by reviewing loaded modules and kernel state, for example lsmod | grep '^tipc', modinfo tipc, and iproute2 TIPC tooling where available. Confirm unnecessary TIPC exposure is removed by verifying that the tipc module is not loaded, TIPC bearers are not configured, and UDP/TIPC transport is not listening or reachable where not required. In test environments, malformed broadcast Gap ACK records should be dropped without KASAN slab-out-of-bounds reports, kernel warnings, or crashes. After remediation, monitor dmesg/journald for absence of tipc_bcast_sync_rcv, tipc_link_advance_transmq, and kmemdup slab-out-of-bounds traces under TIPC traffic.

Typical attack path

1. Identify Linux systems with TIPC enabled, loaded, or reachable over the relevant network segment or UDP/TIPC transport.
2. Establish or simulate TIPC neighbor communication sufficient to send broadcast PROTOCOL/STATE_MSG traffic, including negotiation or use of TIPC_GAP_ACK_BLOCK behavior.
3. Craft a broadcast STATE_MSG with a short data area but a Gap ACK block whose len field matches large ugack_cnt/bgack_cnt-derived structure size.
4. Send the malformed broadcast STATE_MSG to the vulnerable kernel.
5. Trigger the broadcast receive path, causing kmemdup() to read beyond the skb buffer during Gap ACK handling.
6. Observe impact such as kernel log errors, KASAN reports, node crash, panic, service disruption, or possible leakage of adjacent kernel memory through subsequent processing.

How to detect it

To determine whether exploitation may have occurred, review kernel logs, crash dumps, and SIEM-ingested system logs for TIPC receive-path faults, KASAN reports, slab out-of-bounds reads, kernel panics, or unexpected reboots. Relevant log sources include dmesg, journald/kern.log, /var/log/messages, /var/log/kern.log, kernel crash dump facilities such as kdump/vmcore, EDR kernel telemetry, and network sensor logs on cluster or infrastructure segments where TIPC is allowed. Look for stack traces containing kmemdup_noprof, tipc_link_advance_transmq, tipc_link_bc_ack_rcv, tipc_bcast_sync_rcv, tipc_rcv, or tipc_l2_rcv_msg. Network detection should focus on unexpected TIPC protocol traffic, TIPC UDP bearer traffic such as UDP/6118 where used, or broadcast PROTOCOL/STATE_MSG traffic containing anomalous Gap ACK records, especially short message data paired with large Gap ACK length/count fields such as len 0x400, bgack_cnt 0xff, and ugack_cnt 0. Also investigate unexpected loading of the tipc kernel module or new TIPC bearer configuration on systems where TIPC is not normally used.

• BUG: KASAN: slab-out-of-bounds in kmemdup_noprof
• Read of size 1024
• kmemdup_noprof+0x48/0x60
• tipc_link_advance_transmq
• tipc_link_bc_ack_rcv
• tipc_bcast_sync_rcv
• tipc_rcv
• tipc_l2_rcv_msg
• skbuff_small_head
• TIPC_GAP_ACK_BLOCK
• broadcast STATE_MSG
• PROTOCOL/STATE_MSG
• Gap ACK
• bgack_cnt = 0xff
• ugack_cnt = 0
• len = 0x400
• udp port 6118
• modprobe tipc
• kernel: tipc

What your security team should do

• Prioritize patching Linux systems that have TIPC enabled, participate in TIPC clusters, or expose TIPC-capable network paths, especially high-availability and infrastructure nodes.
• Inventory TIPC usage across Linux fleets by checking for loaded tipc modules, configured TIPC bearers, and reachable UDP port 6118 where applicable.
• Disable TIPC on systems that do not explicitly require it and prevent automatic module loading if business applications do not depend on it.
• Restrict TIPC traffic to trusted cluster networks using host firewalls, network ACLs, segmentation, and L2 isolation; block external or user-network access to TIPC transports.
• Search kernel logs and SIEM telemetry for slab-out-of-bounds, KASAN, panic, or crash traces involving TIPC functions listed in the detection guidance.
• Treat unexpected TIPC traffic, unexpected TIPC module loading, or TIPC crashes as high-priority investigation events even though the vulnerability is not currently in CISA KEV and has low EPSS.
• Ensure kernel updates are followed by reboots or live-patch validation so the fixed code is actually running.