---
id: "CVE-2026-98857"
kind: "vulnerability"
aliases: ["CVE-2026-98857"]
title: "Linux kernel IPVS: unbounded LBLC cache growth lets traffic exhaust memory"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["ipvs", "kernel", "linux", "load-balancer", "runtime", "self-hosted"]
not_affected_if: ["no-ipvs", "other-scheduler"]
published_at: "2026-10-18T16:17:40+00:00"
first_seen_at: "2026-10-23T21:57:17+00:00"
updated_at: "2026-10-25T05:12:56+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98857", "first_seen_at": "2026-10-23T21:57:17+00:00"}]
---

# Linux kernel IPVS: unbounded LBLC cache growth lets traffic exhaust memory

The Linux kernel's IPVS load balancer creates a cache entry for every new destination address in its LBLC and LBLCR schedulers, and the size limit only triggers cleanup after it is already exceeded. An attacker sending traffic from many addresses can grow these tables without bound, consuming kernel memory.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Install a kernel release that includes the upstream commit 'ipvs: bound LBLCR and LBLC cache growth'; the sources do not name the fixed version numbers.

## Timeline

- 2026-10-23T21:57:17+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98857

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

ipvs: bound LBLCR and LBLC cache growth

ip_vs_lblcr_new() and ip_vs_lblc_new() create cache entries for
every previously unseen destination address. The table max_size only
tells the periodic collector to reclaim entries after the cache has
already exceeded the limit. It does not reclaim entries that the
attacker continues to use.

Reject new cache entries once either table reaches max_size * 3 / 2.
The extra headroom lets the periodic collector catch up while the
existing scheduler fallback continues to use the selected destination
when cache creation fails. New traffic therefore stays serviceable
without growing the tables further.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_