CVE-2026-98857: Linux Kernel IPVS LBLCR/LBLC DOS Vulnerability

CVE-2026-98857 Overview

CVE-2026-98857 is a resource exhaustion vulnerability in the Linux kernel's IP Virtual Server (IPVS) load balancing subsystem. The flaw affects the Locality-Based Least-Connection with Replication (LBLCR) and Locality-Based Least-Connection (LBLC) schedulers. The functions ip_vs_lblcr_new() and ip_vs_lblc_new() create a cache entry for every previously unseen destination address. The configured max_size only triggers periodic reclamation after the limit is exceeded, so an attacker generating traffic to many distinct destinations can grow the tables faster than the collector reclaims entries.

Critical Impact
Remote attackers can drive unbounded kernel memory consumption on IPVS directors using LBLC or LBLCR scheduling, degrading availability of load-balanced services.

Affected Products

Linux kernel IPVS subsystem (LBLC and LBLCR schedulers)
Distributions shipping affected mainline and stable kernel branches prior to the fix commits
Load balancer appliances and Kubernetes clusters relying on IPVS mode with LBLC/LBLCR schedulers

Discovery Timeline

2026-10-18 - CVE-2026-98857 published to NVD
2026-10-21 - Last updated in NVD database

Technical Details for CVE-2026-98857

Vulnerability Analysis

IPVS provides kernel-level Layer 4 load balancing. The LBLC and LBLCR schedulers maintain hash tables that map destination IP addresses to selected real servers, improving cache locality for repeated flows. Each previously unseen destination address causes ip_vs_lblc_new() or ip_vs_lblcr_new() to allocate a new entry.

The max_size parameter does not act as a hard admission limit. It only informs the periodic collector that reclamation should begin once the table has already crossed that threshold. An attacker generating sustained traffic toward many unique destination addresses continues to force new allocations faster than the collector removes stale entries. The tables grow without an upper bound, consuming kernel slab memory and increasing hash lookup latency.

Root Cause

The root cause is missing admission control in the cache insertion path [CWE-770: Allocation of Resources Without Limits or Throttling]. Reclamation is reactive and periodic, while allocation is unconditional and synchronous. There is no backpressure once max_size is reached, so entries attributable to attacker-controlled destinations are never rejected and persist as long as traffic continues.

Attack Vector

An attacker who can direct traffic through an IPVS virtual service configured with the LBLC or LBLCR scheduler sends packets to a large and continuously changing set of destination addresses. Each new destination inflates the cache. Sustained traffic exhausts memory, can trigger the out-of-memory killer, and degrades scheduler performance across all services sharing the director.

The upstream fix rejects new cache entries once either table reaches max_size * 3 / 2. The extra headroom allows the periodic collector to catch up. When cache insertion fails, the existing scheduler fallback continues selecting a destination, so legitimate traffic remains serviceable without further growing the tables. The patched commits are referenced as 16c83c0, 2a3c3de, 31028d7, 6316d17, and bc9ff8e in the mainline and stable trees.

Detection Methods for CVE-2026-98857

Indicators of Compromise

Sustained growth of IPVS LBLC or LBLCR table sizes beyond the configured max_size without corresponding legitimate traffic patterns
Kernel slab allocator pressure, with ip_vs_lblc or ip_vs_lblcr cache objects consuming unusual memory in /proc/slabinfo
Elevated rates of unique destination IP addresses observed in traffic routed through IPVS virtual services

Detection Strategies

Monitor IPVS statistics using ipvsadm -L --stats and ipvsadm --list --rate for abnormal connection distribution across many unique destinations
Alert on kernel memory consumption anomalies for the ip_vs module, correlating with network flow telemetry
Baseline the expected number of unique destination addresses per virtual service and alert on sudden expansion

Monitoring Recommendations

Collect /proc/net/ip_vs and /proc/net/ip_vs_conn telemetry at regular intervals and forward to a centralized data lake for trend analysis
Instrument node-level memory and slab metrics on IPVS directors and Kubernetes nodes using kube-proxy in IPVS mode
Correlate kernel ring buffer messages indicating memory pressure or OOM activity with IPVS table growth events

How to Mitigate CVE-2026-98857

Immediate Actions Required

Apply the stable kernel update containing commits 16c83c0, 2a3c3de, 31028d7, 6316d17, or bc9ff8e as provided by your distribution
Inventory IPVS virtual services and identify any configured with the lblc or lblcr scheduler
Where feasible, temporarily switch affected virtual services to a scheduler that does not maintain per-destination caches, such as rr, wrr, or wlc

Patch Information

The fix bounds LBLC and LBLCR cache growth by rejecting new entries once either table reaches max_size * 3 / 2. Patch references are available in the upstream Linux kernel tree: Commit 16c83c0, Commit 2a3c3de, Commit 31028d7, Commit 6316d17, and Commit bc9ff8e. Apply the vendor kernel package that incorporates these commits and reboot the affected IPVS directors.

Workarounds

Replace lblc or lblcr schedulers with rr, wrr, lc, or wlc on exposed virtual services where cache locality is not required
Restrict traffic reaching IPVS directors with upstream filtering so untrusted sources cannot generate arbitrary destination addresses
Lower the configured max_size for LBLC/LBLCR tables to reduce the memory ceiling until patches are deployed

bash

# Inspect current IPVS scheduler assignments
ipvsadm -L -n

# Switch an existing virtual service from lblcr to wlc as a temporary mitigation
ipvsadm -E -t <VIP>:<PORT> -s wlc

# Observe LBLC/LBLCR slab usage for anomalous growth
grep -E 'ip_vs_lblc|ip_vs_lblcr' /proc/slabinfo