From: tjdqudcks0424@naver.com
To: horms@verge.net.au, ja@ssi.bg
Cc: pablo@netfilter.org, netdev@vger.kernel.org,
lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,
성병찬 <tjdqudcks0424@naver.com>,
stable@vger.kernel.org
Subject: [PATCH net] ipvs: prevent LBLCR destination leak after entry expiry
Date: Wed, 30 Sep 2026 02:07:46 +0900 [thread overview]
Message-ID: <20260929170747.503223-1-tjdqudcks0424@naver.com> (raw)
From: 성병찬 <tjdqudcks0424@naver.com>
ip_vs_lblcr_schedule() looks up a cache entry under RCU before taking
svc->sched_lock. The expiry timer can remove that entry from the hash
table and erase its destination set before the scheduler takes the lock.
RCU keeps the stale entry itself alive, so the scheduler can continue and
insert a new destination-set element into it. Since the entry is already
unhashed and its set was already erased, no later path finds the new
element. Both the element and its destination reference are leaked when
the parent entry is freed.
Recheck the address mapping while holding svc->sched_lock and update the
set only when the hash table still maps the address to the entry obtained
by the scheduler.
This was found during an AI-assisted source audit. Diagnostic-only timing
instrumentation forced expiry after lookup on a two-vCPU x86-64 QEMU
guest. The unmodified code inserted into the stale entry and left one
element outstanding in each of three runs; kmemleak reported the related
allocation in one run. With this change, the same stale-entry condition
was reached in three runs, but no stale insertion or outstanding element
remained.
An unforced 679-second run processed 65,536 marked packets without hitting
the race. The result therefore confirms the lifetime leak and the effect
of the fix under forced timing, but does not establish practical remote
resource exhaustion.
Fixes: c5549571f975 ("ipvs: convert lblcr scheduler to rcu")
Cc: stable@vger.kernel.org
Signed-off-by: 성병찬 <tjdqudcks0424@naver.com>
---
net/netfilter/ipvs/ip_vs_lblcr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_lblcr.c b/net/netfilter/ipvs/ip_vs_lblcr.c
index f53f05ceea36..ef18f3c9d5da 100644
--- a/net/netfilter/ipvs/ip_vs_lblcr.c
+++ b/net/netfilter/ipvs/ip_vs_lblcr.c
@@ -686,7 +686,8 @@ ip_vs_lblcr_schedule(struct ip_vs_service *svc, const struct sk_buff *skb,
/* Update our cache entry */
spin_lock_bh(&svc->sched_lock);
- if (!tbl->dead)
+ if (!tbl->dead &&
+ ip_vs_lblcr_get(svc->af, tbl, &iph->daddr) == en)
ip_vs_dest_set_insert(&en->set, dest, true);
spin_unlock_bh(&svc->sched_lock);
goto out;
--
2.43.0
next reply other threads:[~2026-09-29 17:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 17:07 tjdqudcks0424 [this message]
2026-09-30 7:44 ` [PATCH net] ipvs: prevent LBLCR destination leak after entry expiry Pablo Neira Ayuso
2026-09-30 15:38 ` Julian Anastasov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260929170747.503223-1-tjdqudcks0424@naver.com \
--to=tjdqudcks0424@naver.com \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=lvs-devel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox