All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: tjdqudcks0424@naver.com
Cc: horms@verge.net.au, ja@ssi.bg, netdev@vger.kernel.org,
	lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH net] ipvs: prevent LBLCR destination leak after entry expiry
Date: Wed, 30 Sep 2026 09:44:18 +0200	[thread overview]
Message-ID: <ary90qdwBnCVwv0p@chamomile> (raw)
In-Reply-To: <20260929170747.503223-1-tjdqudcks0424@naver.com>

Please, stop posting fixes for patches that already exist.

If you want to use a LLM to fix bugs that's great, but you have to
track what is going on the mailing list already.

Thank you.

On Wed, Sep 30, 2026 at 02:07:46AM +0900, 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_insert(&en->set, dest, true);
>  		spin_unlock_bh(&svc->sched_lock);
>  		goto out;
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-09-30  7:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29 17:07 [PATCH net] ipvs: prevent LBLCR destination leak after entry expiry tjdqudcks0424
2026-09-30  7:44 ` Pablo Neira Ayuso [this message]
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=ary90qdwBnCVwv0p@chamomile \
    --to=pablo@netfilter.org \
    --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=stable@vger.kernel.org \
    --cc=tjdqudcks0424@naver.com \
    /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 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.