Re: [PATCH net] ipvs: fix infinite loop with ipvlan L3 from unconditional ipvs_property clear

[Julian Anastasov <ja@ssi.bg>]

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


	Hello,

On Mon, 28 Sep 2026, Chenguang Zhao wrote:

> On Fri, Sep 25, 2026 at 03:42:42PM +0300, Ido Schimmel wrote:
> > On Thu, Sep 24, 2026 at 02:33:12PM +0800, Chenguang Zhao wrote:
> > > From: Chenguang Zhao <zhaochenguang@kylinos.cn>
> > > 
> > > Commit de2c211868b9 ("ipvs: Always clear ipvs_property flag in
> > > skb_scrub_packet()") moved ipvs_reset() before the xnet check, making
> > > the call unconditional. The intent was to fix a bpf_redirect case where
> > > stale ipvs_property on an skb re-entering the RX path caused the SNAT
> > > hook to be skipped. However the change is too broad: when IPVS NAT
> > > sits above an ipvlan L3 interface in the same netns, the following
> > > loop happens:
> > > 
> > >   LOCAL_OUT -> IPVS DNAT (sets ipvs_property=1) -> dst_output -> ipvlan
> > >     -> skb_scrub_packet() -> ipvs_reset() clears the flag
> > >     -> ipvlan_process_v4_outbound() -> ip_local_out() -> LOCAL_OUT
> > >     -> IPVS sees ipvs_property=0, processes again -> infinite recursion
> > > 
> > > syzbot reported this as a stack overflow on a KASAN kernel where each
> > > level burns ~3.3 KB of stack and XMIT_RECURSION_LIMIT falls short. On
> > > non-KASAN kernels the dead-loop detector catches it and prints "Dead
> > > loop on virtual device", but traffic is still broken.
> > > 
> > > Fixes: de2c211868b9 ("ipvs: Always clear ipvs_property flag in skb_scrub_packet()")
> > > Reported-by: syzbot+2b120190d9e54ad8c65d@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=2b120190d9e54ad8c65d
> > > Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
> > 
> > 1. You need to copy IPVS maintainers on patches related to IPVS. Added
> > Julian.
> 
> Thanks, will add Julian to CC in v2.

	I saw it the first time, not needed. But I was busy
with other changes, sorry for that. May be the packet scrubing
needs 3 states, not just 2. But as this is not my area I have
to dig more. SCRUB_REROUTE/SCRUB_TUNNEL (xdev=false, no ipvs_reset)
used by IPVLAN L3, SCRUB_FORWARD (xdev=false, ipvs_reset) used
by bpf_redirect in same netns, SCRUB_NET (xdev=true). But there
are many call sites to check. The problem is to know how far
a packet can reach without reset.

	Another option is to add new skb_scrub_packet_XXX() for the
needed sites, I'm not sure. But adding IPVS code in the IP layer
does not look nice.

> > 
> > 2. Does it reproduce with commit 7f1de03e3103 ("net: reduce
> > XMIT_RECURSION_LIMIT under KASAN") in net-next?
> 
> The dead loop itself still reproduces — dmesg shows "Dead loop on virtual device" for
> every connection, and IPVS InPkts keeps climbing. But the stack overflow crash does not
> reproduce with 7f1de03e3103 on KASAN, since the lower recursion limit catches the loop
> before the stack blows up. So 7f1de03e3103 turns the panic into a packet drop,
> which is expected, but doesn't fix the underlying issue (ipvs_property being cleared
> unconditionally in skb_scrub_packet).
> 
> Thanks
> Chenguang

Regards

--
Julian Anastasov <ja@ssi.bg>