Cloudanix VulnDB

CVE-2026-98794

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux load-balancing feature could be tricked by bad messages from another server into mishandling connections, and a fix now rejects those messages before they cause problems.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Improper validation of connection flags in IPVS sync protocol messages allows a backup server to accept and process NO_CPORT+TEMPLATE or ONE_PACKET combinations that the master never sends, leading to incorrect connection template lookups, unhashed connections, or other state corruption on the backup.

Why it matters to the business

Organizations using Linux IPVS load balancing in active-backup configurations face risk of backup server instability or incorrect traffic handling if an attacker can reach the sync channel, potentially causing brief service disruption during failover or recovery.

How an attack unfolds

An attacker positioned to inject traffic on the IPVS sync protocol port sends crafted v0 or v1 sync messages containing disallowed flag combinations; the backup server processes them instead of dropping, resulting in broken connection state that can affect subsequent lookups or cause immediate drops.

How to fix it

Upgrade to a Linux kernel version containing the fix for improper flag handling in ip_vs_sync; apply the patch that enforces IP_VS_CONN_F_BACKUP_MASK on both v0 and v1 messages and drops the disallowed combinations.

How to confirm the fix worked

Confirm the kernel source contains the updated ip_vs_sync.c logic that rejects NO_CPORT+TEMPLATE and applies the backup mask to ONE_PACKET; test by replaying sync messages with the previously accepted flag combinations and verifying they are now dropped.

Typical attack path

  1. Identify exposed IPVS sync port between master and backup nodes
  2. Craft sync protocol messages with NO_CPORT+TEMPLATE or ONE_PACKET flags
  3. Transmit messages to the backup server
  4. Observe resulting connection state corruption or template lookup failures on the backup

How to detect it

Review IPVS sync protocol logs or packet captures on backup nodes for inbound messages containing NO_CPORT combined with TEMPLATE or the ONE_PACKET flag; correlate with any resulting unhashed connection entries or template lookup errors in kernel logs.

What your security team should do

  • Prioritize kernel updates on all IPVS backup nodes within the next maintenance window
  • Restrict IPVS sync protocol traffic to trusted master IPs using firewall rules
  • Monitor for any unexpected connection template or hash table anomalies on backup servers

The record

In the Linux kernel, the following vulnerability has been resolved: ipvs: filter some flags received in the backup server While the IPVS SYNC protocol is not secure by design we can still protect the backup server from messages that can wreak havoc. This commit addresses problems from received connection flags or their combinations. We now drop messages as follows: 1. the NO_CPORT+TEMPLATE combination allows lookups for normal connections to hit template which can break in many ways. While the master does not sync connections with NO_CPORT flag, i.e. before they are established, we still accept NO_CPORT without TEMPLATE. 2. ONE_PACKET: it is not sent by master, so we do not expect it in backup. Before now it was ignored by IP_VS_CONN_F_BACKUP_MASK for protocol v1 while protocol v0 created connections that are not hashed and dropped immediately. Better to apply the IP_VS_CONN_F_BACKUP_MASK also to the flags from v0 messages for consistency with v1.

Affected packages

Ecosystem Package Introduced Fixed