EUVD-2026-103595
GHSA-xqp5-j42w-5fq8
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach TIPC group socket on target host
-
ExploitSend invalid/stale GRP_ACK_MSG
-
ExecutionUnderflow u16 bc_ackers to 65535
-
ImpactPermanent congestion blocks all group broadcasts
Vulnerability Assessment
| Exploitation Conditions | Requires the Linux kernel TIPC protocol to be loaded and an active TIPC group-communication (replicast broadcast) socket on the target; TIPC is not enabled by default in most distributions. The attacker must be able to deliver a GRP_ACK_MSG to that group - either an unexpected ACK with acked > m->bc_acked while grp->bc_ackers is zero (quiet group / replicast ACKs not requested / all members already acknowledged), or a stale/out-of-sequence ACK (e.g. value S) during an active round exploiting the 2-sequence gap. Limiting factors: TIPC must be reachable via its L2 (Ethernet) or configured UDP bearer, the target must actually use TIPC group messaging, and impact is confined to availability - the affected socket's group broadcasts are permanently blocked, with no code execution, privilege gain, or data exposure. |
| Impact | Signals are consistent and point to a moderate, availability-only Linux kernel flaw rather than a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) encodes a pure denial-of-service: no confidentiality or integrity impact, only availability. EPSS is low at 0.21% (11th percentile), there is no CISA KEV listing, and no public exploit or PoC reference is supplied - only vendor patch commits. The vuln.today decision label is 'this_week', which aligns with a patch-available DoS that is worth scheduled remediation but is not act_now/emergency. The one notable conflict is in the input metadata: the Tags claim 'Information Disclosure', but the CVSS vector is C:N/I:N/A:H - there is no confidentiality impact, so that tag is wrong and this is a broadcast-blocking DoS, not disclosure. A second caveat is scope of exposure: although the vector is AV:N, the flaw lives in the TIPC subsystem, which is rarely loaded or used in production; real-world attack surface is far smaller than a 7.5 network DoS against the Linux kernel would suggest. Net: patch on a normal maintenance cycle; it is not a drop-everything issue. |
| Exploit ScenarioDerived | An attacker with reach to a TIPC group communication socket sends an invalid or unexpected GRP_ACK_MSG. On a quiet group (grp->bc_ackers == 0) this decrements the u16 bc_ackers below zero, wrapping it to 65535 so tipc_group_bc_cong() permanently reports congestion and silently blocks all future group broadcasts on that socket. No public exploit or PoC reference is provided; exploitation would require crafting TIPC group ACK traffic against a host with TIPC in use. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
An unexpected or stale GRP_ACK_MSG delivered to a TIPC replicast broadcast group can drive the kernel's u16 grp->bc_ackers counter below zero, wrapping it to 65535 and causing tipc_group_bc_cong() to report permanent congestion - blocking all future group broadcasts on that socket. Unprivileged, unauthenticated remote attackers can trigger the defect (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) provided TIPC is loaded and a group-communication socket is active, which is not the case on default distribution installs. Impact is strictly availability on the affected socket, with no code execution, privilege escalation, or data exposure; no public exploit has been identified and EPSS is low (0.21%, 11th percentile), though the vendor has released fixed kernels and the issue is tracked for the current weekly patch cycle.
RemediationAI
Apply the vendor-supplied kernel update for your branch: 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.55, 7.2.9, or 7.3-rc5 (or later), or pick up stable commits edc6593c442278fceff0120e8cc58bc592168c35, 9b94a90651e1fa573c6ac6a5a6b269d5874df2c0, 507a27435b2bb1f22e3a3674f6a6553eb815021b, 80a9ccfc24d3776ef6753a57315e726475fac7d7, 478fb08d0c2a53002a721d22b8d6681ec971d90f, 12cc3a1eac5a2a06b67a7b85f0f48ff241a94d1b, b0e517961f09b9f60d338d1ea4e17aacdbf206f0 or 99cc2a62e07a44a22254d7beca9ef1f8ad886d0d from git.kernel.org; because a trigger requires TIPC to be loaded and a live replicast group socket, the interim compensating control is to ensure the tipc module is not loaded (blacklist/do not modprobe it, or build with TIPC disabled) or, where TIPC must run, restrict reachability of its L2/UDP bearer to trusted peers via switch ACLs, VLAN separation or host firewall rules on the configured UDP bearer port - accepting that these controls only shrink the attacker population and do not fix the counter underflow, and that disabling or firewalling TIPC breaks legitimate inter-process/cluster messaging for any application relying on it. Note that a related socket-wakeup gap on member departure is being fixed separately.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
TIPC (Transparent Inter-Process Communication) is an in-kernel messaging protocol that provides cluster-local and cluster-interconnect messaging over L2 (Ethernet) or configured UDP bearers, including multicast-like 'replicast' group broadcasts that request acknowledgements from group members. The flaw lives in tipc_group_proto_rcv(), the handler for service-level protocol messages such as GRP_ACK_MSG. An earlier fix (commit 48a5fe38772b, 'tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG') returned early only when less_eq(acked, m->bc_acked), which left two gaps: (1) with grp->bc_ackers already at zero - a quiet group, a group where replicast ACKs were never requested, or one where every member has already acknowledged - a GRP_ACK_MSG carrying acked > m->bc_acked still passes the check and unconditionally decrements the u16 counter, wrapping it to 65535; and (2) during an active round, tipc_group_update_bc_members() seeds each member's m->bc_acked to grp->bc_snd_nxt - 1 while the only legitimate ACK value is grp->bc_snd_nxt, leaving a two-sequence gap in which an ACK for S (rather than S+1) is neither treated as a duplicate nor prevented from decrementing bc_ackers, letting a single member decrement twice in one round. The patch therefore drops GRP_ACK_MSG outright when grp->bc_ackers is zero and requires acked == grp->bc_snd_nxt while rejecting acked duplicates already recorded in m->bc_acked, since replicast rounds are strictly sequential and each member may acknowledge at most once per round. No CWE was supplied; the defect class is a logic/validation error leading to an integer underflow of a reference counter. Note that a related pre-existing gap in tipc_group_delete_member() - where bc_ackers reaching zero on member departure does not restore *grp->open or wake the socket - is explicitly deferred to a separate patch. The 'Information Disclosure' feed tag attached to this CVE is inconsistent with the assessed availability-only impact.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
TIPC has no per-message authentication so PR:N, a single crafted ACK triggers the underflow so AC:L, and impact is availability-only (persistent broadcast block) hence C:N/I:N/A:H.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow
Commit 48a5fe38772b ("tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG") rejected duplicate/stale ACKs in tipc_group_proto_rcv() by returning early when less_eq(acked, m->bc_acked).
However, that check remains incomplete in two ways:
- When grp->bc_ackers is zero (e.g. on a quiet group, when replicast
ACKs were not requested, or after all expected members have already acknowledged), an unexpected GRP_ACK_MSG with acked > m->bc_acked passes less_eq() and unconditionally decrements grp->bc_ackers. Because bc_ackers is a u16, this wraps to 65535, causing tipc_group_bc_cong() to permanently report congestion and blocking all future group broadcasts on the socket.
- During an active broadcast round (grp->bc_ackers > 0), the sender
transmits packet S and advances grp->bc_snd_nxt to S + 1. Receivers increment their expected counter to S + 1 upon consuming packet S, so the only valid ACK value for the current round is strictly acked == grp->bc_snd_nxt.
However, tipc_group_update_bc_members() initializes each member's m->bc_acked to prev = grp->bc_snd_nxt - 1 (S - 1 before increment). This leaves a 2-sequence gap (S - 1 to S + 1) in sequence space. An incoming ACK is therefore neither rejected as duplicate nor prevented from decrementing grp->bc_ackers if an unexpected or stale value (such as S) is received. A member sending acked = S followed by acked = S + 1 could decrement grp->bc_ackers twice in the same round, prematurely clearing bc_ackers or underflowing it.
Fix this by:
- Dropping GRP_ACK_MSG immediately if grp->bc_ackers is zero.
- Requiring acked == grp->bc_snd_nxt and rejecting duplicates where
m->bc_acked == acked. Because replicast broadcast rounds are strictly sequential, only grp->bc_snd_nxt can be acknowledged, and each member can acknowledge at most once per round.
Note that a related pre-existing issue in tipc_group_delete_member() (where grp->bc_ackers decrementing to zero upon member departure does not restore *grp->open or trigger a socket wakeup) will be addressed in a separate patch.
Executive ViewAI
A high-severity flaw in the Linux kernel's TIPC broadcast group implementation (CVE-2026-98550) could allow an unauthenticated remote attacker to cause permanent denial of service on affected sockets, but only if TIPC is loaded and group communication is active-configurations not present by default on standard distributions. Leadership should prioritize patching where TIPC is in use to prevent potential broadcast outages, though overall organizational risk is limited due to low exposure and no observed exploitation.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB