CVE-2026-31662

What it actually does

This is a network-reachable denial-of-service flaw in the Linux kernel TIPC group protocol handling. The vulnerable code path in tipc_group_proto_rcv() decrements the 16-bit bc_ackers broadcast-acknowledgement counter every time a GRP_ACK_MSG is received, even if that group member has already acknowledged the current broadcast round. A duplicate or stale ACK can therefore decrement the counter past zero, wrapping it to 65535. After the wraparound, tipc_group_bc_cong() continues to treat the group socket as congested, causing later group broadcasts on that socket to remain blocked until the affected group is recreated. The impact is availability loss for applications relying on TIPC group broadcast messaging; it does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Systems that use Linux TIPC for clustered or distributed application messaging can experience stalled group communication, service degradation, or outages if an attacker can send crafted duplicate group acknowledgement traffic to the TIPC network. Because exploitation is network-based, requires no authentication, and has low attack complexity, exposed TIPC deployments should be treated as higher operational risk even though current EPSS is low, stable, and the vulnerability is not listed in CISA KEV. Organizations not using TIPC are unlikely to be affected in practice, but should still track kernel updates because TIPC may be enabled in specialized high-availability, telecom, embedded, or clustered environments.

How an attack unfolds

An attacker first identifies a Linux host or cluster where TIPC is enabled and reachable, typically on a trusted cluster network, Ethernet bearer, or UDP bearer. The attacker then targets an active TIPC group socket involved in broadcast communication. During or after a normal broadcast acknowledgement round, the attacker sends duplicate or stale GRP_ACK_MSG traffic for a member that has already acknowledged the current round. On vulnerable kernels, the handler decrements bc_ackers again instead of ignoring the duplicate ACK. If the duplicate arrives after the last legitimate acknowledgement, the unsigned 16-bit counter underflows and wraps to 65535. The kernel then believes the group broadcast path remains congested, so future broadcasts for that affected socket stay blocked. The attacker can repeat this against active group communication to disrupt applications that depend on TIPC messaging. There is no indication from the provided data of public exploit maturity, ransomware use, or named threat actor exploitation.

How to fix it

Apply the relevant Linux kernel update from the operating system or appliance vendor that includes the TIPC fix for duplicate or stale GRP_ACK_MSG handling. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs for the deployed distribution to identify the corrected build. After updating, reboot if required so the fixed kernel is active. If immediate patching is not possible, reduce exposure by disabling TIPC where it is not required, preventing the tipc kernel module from loading, and restricting TIPC bearer traffic to trusted cluster peers only. Network controls should block untrusted access to TIPC Ethernet bearer traffic and TIPC UDP bearer traffic where UDP bearers are used, commonly including UDP port 6118 unless configured otherwise. For systems that require TIPC, segment the cluster network, allow only known peer addresses, and monitor for anomalous duplicate group acknowledgement traffic.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the TIPC duplicate GRP_ACK_MSG underflow fix; checking only installed packages is insufficient if the system has not rebooted into the fixed kernel. Verify exposure by determining whether TIPC is enabled or loaded, whether TIPC bearers are configured, and whether applications use TIPC group communication. Useful checks include reviewing loaded kernel modules, kernel configuration, distribution package changelogs, and TIPC bearer configuration through system tooling. Validate mitigation by confirming untrusted networks cannot reach TIPC bearers and that only expected cluster peers can communicate. In a controlled lab, regression testing can verify that replayed duplicate or stale GRP_ACK_MSG packets no longer cause persistent group broadcast congestion or blocked group sends.

Typical attack path

1. Identify Linux systems or clusters with TIPC enabled and reachable over a network bearer.
2. Confirm or infer that TIPC group broadcast messaging is in use by observing cluster/application traffic or service behavior.
3. Craft or replay duplicate/stale TIPC GRP_ACK_MSG packets associated with an active group acknowledgement round.
4. Send the duplicate ACK after a member has already acknowledged the current broadcast round, ideally after the last legitimate ACK.
5. Trigger bc_ackers underflow from 0 to 65535 on the vulnerable kernel.
6. Cause tipc_group_bc_cong() to keep reporting congestion, blocking later broadcasts on the affected group socket.
7. Maintain or repeat the condition to degrade clustered application communication until the group/socket is recreated or the host is remediated.

How to detect it

To assess possible prior exploitation, focus on environments where TIPC was enabled and reachable. Review network telemetry, packet captures, IDS data, and firewall logs for unexpected TIPC traffic from non-cluster peers, especially repeated group acknowledgement patterns or unusual traffic bursts around service degradation. If TIPC UDP bearers are used, inspect UDP traffic to the configured TIPC bearer port, commonly UDP/6118, and look for sources outside the expected peer set. If Ethernet bearers are used, inspect L2 telemetry or packet captures for TIPC EtherType 0x88CA from unauthorized MAC addresses. On hosts, review kernel logs and application logs for periods where TIPC-based group communication stalled, clustered services reported messaging timeouts, or recovery required recreating groups, restarting services, or rebooting. Absence of logs does not rule out exploitation because the vulnerability may manifest primarily as blocked group broadcasts rather than a distinct kernel error. If packet captures are available from the incident window, prioritize protocol-level review for duplicate or stale GRP_ACK_MSG messages associated with the same group acknowledgement round.

• TIPC EtherType 0x88CA
• udp port 6118
• UDP/6118
• GRP_ACK_MSG
• tipc_group_proto_rcv
• tipc_group_bc_cong
• bc_ackers
• tipc

What your security team should do

• Prioritize patching Linux systems where TIPC is enabled, reachable over the network, or used for clustered/high-availability application messaging.
• Inventory hosts for TIPC usage, including loaded tipc modules, configured TIPC bearers, and applications linked to or configured for TIPC communication.
• Disable TIPC on systems that do not explicitly require it and prevent automatic loading of the tipc kernel module where feasible.
• Restrict TIPC traffic to trusted cluster peers using host firewalls, network ACLs, segmentation, or bearer-specific controls.
• Review network telemetry for unexpected TIPC traffic, especially from non-cluster hosts or across security boundaries.
• Monitor kernel and application logs for symptoms of stalled TIPC group communication, repeated congestion, or unexplained cluster messaging failures.
• Because EPSS is currently low and no KEV listing or public exploit maturity is reported, use exposure-based prioritization rather than broad emergency response for systems that do not use TIPC.