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

[Julian Anastasov <ja@ssi.bg>]

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


	Hello,

On Mon, 21 Sep 2026, netdev-bot+sashiko@kernel.org 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@nebusec.ai/

	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@ssi.bg>