Re: [PATCH net] ipvs: prevent LBLCR destination leak after entry expiry

[Julian Anastasov <ja@ssi.bg>]

[-- Attachment #1: Type: text/plain, Size: 2714 bytes --]


	Hello,

On Wed, 30 Sep 2026, tjdqudcks0424@naver.com wrote:

> 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_eraseall() does not update set->size, what if
we use atomic_set(&set->size, -1) there and to check it here to
avoid inserting dest into dying en? This should reduce the time
while we hold sched_lock.

		if (!tbl->dead && atomic_read(&en->set.size) >= 0)

>  			ip_vs_dest_set_insert(&en->set, dest, true);
>  		spin_unlock_bh(&svc->sched_lock);
>  		goto out;
> -- 
> 2.43.0

Regards

--
Julian Anastasov <ja@ssi.bg>