CVE-2026-98857

What it actually does

Unbounded growth of LBLCR and LBLC IPVS cache tables when new destination addresses are presented, because max_size only triggers post-exceedance reclamation by the periodic collector and does not prevent attacker-controlled continued use of entries.

Why it matters to the business

Load-balanced services using these schedulers can experience memory exhaustion and degraded performance or denial of service when exposed to traffic with many unique destinations, increasing operational risk for high-availability environments.

How an attack unfolds

An attacker generates traffic flows that each target a previously unseen destination address, causing ip_vs_lblcr_new and ip_vs_lblc_new to allocate new cache entries without limit; the periodic collector cannot keep pace, leading to uncontrolled table growth and eventual resource exhaustion.

How to fix it

Apply the kernel patch that enforces rejection of new cache entries once either table reaches max_size * 3 / 2, allowing the periodic collector to reclaim entries while preserving fallback scheduling.

How to confirm the fix worked

Confirm the patched kernel rejects cache creation attempts once the threshold is reached and that existing entries continue to be collected; monitor table sizes under synthetic load that previously triggered unbounded growth.

Typical attack path

1. Identify an IPVS-enabled service using LBLCR or LBLC scheduler
2. Generate high-volume traffic with many unique destination addresses
3. Observe cache table growth beyond max_size without reclamation keeping pace
4. Continue traffic to maintain entries and exhaust memory

How to detect it

Inspect kernel logs and IPVS statistics for rapid growth in lblcr or lblc cache entry counts; correlate with traffic patterns containing many distinct destination addresses; look for memory pressure warnings on systems running the affected IPVS schedulers.

What your security team should do

• Prioritize patching Linux kernel IPVS instances using LBLCR or LBLC schedulers within the next maintenance window
• Review IPVS configuration for use of these schedulers and consider migrating to bounded alternatives if patching is delayed
• Monitor memory usage of ip_vs cache tables in production load balancers