{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.190-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.113-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.9-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003ebc_acked).  However, that check remains incomplete in two ways:  1. When grp-\u003ebc_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 \u003e m-\u003ebc_acked    passes less_eq() and unconditionally decrements grp-\u003ebc_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-\u003ebc_ackers \u003e 0), the sender    transmits packet S and advances grp-\u003ebc_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-\u003ebc_snd_nxt.     However, tipc_group_update_bc_members() initializes each member's    m-\u003ebc_acked to prev = grp-\u003ebc_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-\u003ebc_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-\u003ebc_ackers twice in the same    round, prematurely clearing bc_ackers or underflowing it.  Fix this by: - Dropping GRP_ACK_MSG immediately if grp-\u003ebc_ackers is zero. - Requiring acked == grp-\u003ebc_snd_nxt and rejecting duplicates where   m-\u003ebc_acked == acked. Because replicast broadcast rounds are strictly   sequential, only grp-\u003ebc_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-\u003ebc_ackers decrementing to zero upon member departure does not restore *grp-\u003eopen or trigger a socket wakeup) will be addressed in a separate patch.",
  "id": "DEBIAN-CVE-2026-98550",
  "modified": "2026-10-19T04:47:45.924141535Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98550"
    }
  ],
  "upstream": [
    "CVE-2026-98550"
  ]
}