Re: [PATCH net 0/1] ipvs: bound twos scheduler destination walks

[Julian Anastasov <ja@ssi.bg>]

	Hello,

On Sun, 13 Sep 2026, Ren Wei wrote:

> From: Darong Lu <zzyy19904204639@163.com>
> 
> Hi Linux kernel maintainers,
> 
> We found and validated an issue in net/netfilter/ipvs/ip_vs_twos.c. The
> bug is reachable by a non-root user via user and net namespace.
> We've tested it, and it should not affect any other functionality.
> 
> We will provide detailed information about the bug
> in this email, along with a PoC to trigger it.
> 
> ---- details below ----
> 
> Bug details:
> 
> The IPVS TWOS scheduler performs two RCU-protected walks over the service
> destination list. The reproducer repeatedly deletes and recreates the
> service, including its destinations, while the scheduler is traversing the
> list. If a destination list entry is relinked before the RCU reader
> completes, the reused entry can make the iterator follow a link outside the
> original service list.
> 
> The root cause is that both walks are unbounded. If the iterator follows a
> reused list entry, it can continue walking indefinitely and prevent the
> scheduler from returning. The fix reads the service destination count before
> each walk and stops after that many entries, while preserving the existing
> scheduler algorithm and RCU list traversal.

	I'm trying to understand how the iterator can be
tricked to loop forever: to loop, it should never reach 
&svc->destinations, so it must walk unlinked nodes which
create some loop between them. But READ_ONCE soon or later
will read actual ptr from memory, so it should reach to
&svc->destinations. We know that entries end up in reverse
order in the list after they are added but how looks the
list that causes the loop?

	OTOH, I don't understand why we need two full lookups to
trigger the problem, can it happen with one list_for? Other
schedulers also walk the list twice, for example, RR remembers
previous position.

	I assume the problem is caused by the dest_trash.
It seems, we need a general solution to this problem.
One option is to penalize with synchronize_rcu() if we detect
dest that is reused too soon. But even that looks complex to
implement.

Regards

--
Julian Anastasov <ja@ssi.bg>