Re: [PATCH net v2 1/2] ipvs: avoid stack overflow from recursive connection expiration

[zihan xi]

On Mon, Sep 21, 2026 at 2:50 PM Julian Anastasov <ja@xxxxxx> wrote:
>
>
>         Hello,
>
> On Mon, 21 Sep 2026, netdev-bot+sashiko@xxxxxxxxxx wrote:
>
> > Thank you for your contribution! Sashiko AI review found 2 potential
> > issue(s) to consider.
> >
> > Critical: 0 · High: 1 (1) · Medium: 0 · Low: 1
> >
> > If you believe none of the issues are legitimate, please reply to each
> > issue of Medium severity or higher and explain why the AI is wrong.
> > If any of them are legitimate and you plan to respin, please let patchwork
> > know by including "pw-bot: cr" as a separate line at the end of your reply
> > (one such reply per series is enough).
> >
> > - [High] ipvs: use-after-free in ip_vs_conn_expire() due to timer re-
> >   arming race
> > - [Low] ip_vs_conn_del_put() (net/netfilter/ipvs/ip_vs_conn.c:1333-1346)
> >   keeps its old comment "Try to delete connection while holding…
> >
> > Pre-existing issues:
> > - [High] ip_vs_conn_del_put() (net/netfilter/ipvs/ip_vs_conn.c:1336-1341)
> >   cancels the controller's timer, drops the caller's only reference on…
> >
> > --
> >
> > ipvs: avoid stack overflow from recursive connection expiration
> >
> > This changes ip_vs_conn_del_put() to return whether it managed to delete
> > the controller's timer, and makes ip_vs_conn_expire() loop back with the
> > controller instead of recursing into itself.  The stated goal is to keep
> > chain cleanup synchronous while using a single stack frame.
> >
> > v1 Link: https://lore.kernel.org/all/cover.1789110326.git.zihanx@xxxxxxxxxx/
>
>         Zihan, IPVS has conn refcounting which does not look
> natural: the hash table has reference and the timer callback
> has no reference. Let me try today to change the refcounting,
> so that unhashing occurs after last reference is dropped,
> the conn lookups already use inc_not_zero, so we will try
> to consider the timer_delete as successful stealing of
> the refcnt from the timer callback (yes, the callback should
> hold refcnt, not the hashing). But first let me try if the
> idea would be successful. As result, your change should
> be small as before, we should be able to delete conns safely.
>
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>

Hello Julian,

Thanks for looking into this.

The Sashiko report was generated for v2. I have already sent v3:
https://lore.kernel.org/all/cover.1789877273.git.zihanx@xxxxxxxxxx/

I'll wait for your refcounting changes and then rework the iterative
expiration fix on top of them.

Regards,
Zihan