All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 nf 0/2] ipvs: fix LBLC and LBLCR cache growth
@ 2026-09-10 10:08 Julian Anastasov
  2026-09-10 10:08 ` [PATCH v4 nf 1/2] ipvs: fix missing counter decrement in lblc Julian Anastasov
  2026-09-10 10:08 ` [PATCH v4 nf 2/2] ipvs: bound LBLCR and LBLC cache growth Julian Anastasov
  0 siblings, 2 replies; 3+ messages in thread
From: Julian Anastasov @ 2026-09-10 10:08 UTC (permalink / raw)
  To: Simon Horman
  Cc: Pablo Neira Ayuso, Florian Westphal, lvs-devel, netfilter-devel,
	Zhiling Zou, vega


        Hello,

        Following is a patchset with two changes:

1. fix for a missing decrement in LBLC

2. v3 of the LBLC/LBLCR patch from Zhiling Zou applied on top of the
first patch, as v4

        Zhiling Zou <zhilinz@nebusec.ai> explained the problem in v3:

We found and validated an issue in net/netfilter/ipvs/ip_vs_lblcr.c.
The bug is reachable by a non-root user through a new user and network
namespace. The same cache growth bound is also missing from the sibling
LBLC scheduler in net/netfilter/ipvs/ip_vs_lblc.c.

Bug details:

ip_vs_lblcr_new() allocates and publishes an LBLCR cache entry for
every previously unseen destination address. Although tbl->max_size is
initialized to 16384 entries, it is only used by the periodic collector
after cache growth has already exceeded the limit. The collector runs
once per minute and does not reclaim recently used entries.

An attacker can configure a fwmark-based LBLCR service and
continuously send UDP packets to distinct destination addresses. Each
new address creates an entry, allowing the table to grow without bound.
The allocations use GFP_ATOMIC and are not charged to the originating
socket or memory cgroup.

LBLC uses the same cache model and periodic collector. Bound new LBLC
cache entries the same way so both scheduler variants stop growing after
their table reaches max_size * 3 / 2.

The scheduler selects a destination before attempting to cache it and
already continues to use that destination when cache creation fails.
The fix therefore rejects only new cache entries once the table reaches
max_size * 3 / 2, while normal traffic to new addresses remains
serviceable without further cache growth.


Julian Anastasov (1):
  ipvs: fix missing counter decrement in lblc

Zhiling Zou (1):
  ipvs: bound LBLCR and LBLC cache growth

 net/netfilter/ipvs/ip_vs_lblc.c  | 4 ++++
 net/netfilter/ipvs/ip_vs_lblcr.c | 3 +++
 2 files changed, 7 insertions(+)

-- 
2.55.0



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-09-10 10:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-10 10:08 [PATCH v4 nf 0/2] ipvs: fix LBLC and LBLCR cache growth Julian Anastasov
2026-09-10 10:08 ` [PATCH v4 nf 1/2] ipvs: fix missing counter decrement in lblc Julian Anastasov
2026-09-10 10:08 ` [PATCH v4 nf 2/2] ipvs: bound LBLCR and LBLC cache growth Julian Anastasov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.