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

[Chenguang Zhao <chenguang.zhao@linux.dev>]

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.
> 
> 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