Skip to main content
No exploitation reported

CVE-2026-98550

tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow

No exploitation reported by the sources we read.

  • Published2026-10-18

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

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.

Timeline

dates in UTC
  1. 2026-10-1816:17CVE publishedNVD

Observed activity

isMalicious corpus · updated 2026-10-24 15:37 UTC
Indicators tagged with this CVE, per day0 indicators over 7 days
Block these indicators
  • Firewall list (EDL, text): https://api.ismalicious.com/edl/cve/CVE-2026-98550?format=txt
  • CSV export: https://api.ismalicious.com/edl/cve/CVE-2026-98550?format=csv
  • TAXII collection of exploited CVEs
  • The EDL and CSV take an API key on the Pro plan.

Versions per branch

Distribution builds and vendor advisories

Packages from OSV.dev and products from the vendors' CSAF advisories.

version not verifiedVersions not verified: read as OSV.dev and the vendors publish them, not checked against each vendor's release list.

Vendor advisories

  • CVE-2026-98550 Red Hat Product Security235 known affected

    kernel: tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow

    kernel as a component of Red Hat Enterprise Linux 10 · kernel-64k as a component of Red Hat Enterprise Linux 10 · kernel-64k-core as a component of Red Hat Enterprise Linux 10 · +232 more

Full record on NVD

Fix

  1. Workaround from the vendor Red Hat Product Security CVE-2026-98550 · 235 products--- CME Mitigation Guidance (2026-10-20) --- Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to indepen…
  2. No fix available, says the vendor Red Hat Product Security CVE-2026-98550 · 235 productsAffected

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof-of-concept repositories
none listed
PoC-in-GitHub

Sources

  • NVDCVE recordread 2026-10-24
  • CNACVSS 3.17.5read 2026-10-24
  • FIRST EPSSEPSS score0.2 %2026-10-23

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Published
2026-10-18
Last Modified
2026-10-24
NVD status
Received

Frequently asked questions

What is CVE-2026-98550?

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.

Is CVE-2026-98550 actively exploited?

Active exploitation of CVE-2026-98550 has not been confirmed. Its EPSS score was 0.2% on 2026-10-23, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2026-98550?

CVE-2026-98550 has a CVSS v3 base score of 7.5 (HIGH severity), with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

Running Linux kernel? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, October 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database