Description
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:

1. 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.

2. 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.
Published: 2026-10-18
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service
Action: Patch
AI Analysis

Impact

The Linux kernel TIPC subsystem can accept malformed or unexpected group acknowledgment messages (GRP_ACK_MSG) and incorrectly decrement an unsigned 16‑bit counter, bc_ackers. When this counter underflows, it wraps to 65535, causing tipc_group_bc_cong() to report permanent congestion and permanently blocking all future broadcasts on the socket. This results in a denial‑of‑service for applications that rely on TIPC group broadcasts.

Affected Systems

The vulnerability affects any Linux kernel that implements the TIPC stack and has not incorporated commit 48a5fe38772b. No specific kernel release numbers are listed, so all kernels lacking that patch are potentially vulnerable. The exploit requires an attacker capable of injecting TIPC GRP_ACK_MSG packets toward the target host.

Risk and Exploitability

The CVSS score is not provided, the EPSS score is unavailable, and the vulnerability is not in CISA’s KEV catalog, indicating no documented exploitation yet. Exploitation requires the ability to send TIPC GRP_ACK_MSG packets to the target machine, implying either local or remote network access to the vulnerable host. The bug does not provide code execution; it purely causes service disruption.

Generated by OpenCVE AI on October 18, 2026 at 18:08 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the fix for commit 48a5fe38772b.
  • If a kernel upgrade cannot be performed immediately, temporarily disable the TIPC networking stack by unloading the tipc module (modprobe -r tipc) or disabling it via system configuration.
  • After disabling or updating, monitor system logs for TIPC errors and verify that bc_ackers does not underflow by inspecting relevant debug interfaces if available.

Generated by OpenCVE AI on October 18, 2026 at 18:08 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 18 Oct 2026 18:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-734

Sun, 18 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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: 1. 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. 2. 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.
Title tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-18T15:18:18.173Z

Reserved: 2026-09-25T10:25:14.356Z

Link: CVE-2026-98550

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-18T16:17:07.030

Modified: 2026-10-18T16:17:07.030

Link: CVE-2026-98550

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-18T18:15:15Z

Weaknesses