[OpenSIPS-Devel] [OpenSIPS/opensips] 5972c8: net: fix connection reference leak in tcp_async_wr...

[gmaruzz]

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 5972c802c89e8d0f1a1989eec34637919d9abb6f
      https://github.com/OpenSIPS/opensips/commit/5972c802c89e8d0f1a1989eec34637919d9abb6f
  Author: gmaruzz <gmaruzz at users.noreply.github.com>
  Date:   2026-07-29 (Wed, 29 Jul 2026)

  Changed paths:
    M net/net_tcp.c

  Log Message:
  -----------
  net: fix connection reference leak in tcp_async_write_job() (#4125)

When a write job is already queued for the connection, the
F_CONN_WRITE_QUEUED branch of tcp_async_write_job() returns success
without releasing the caller's reference. All three call sites treat a
successful return as a transfer of ownership:

 * tcp_conn_release() (net_tcp_proc.c) returns without tcpconn_put() on
   success, releasing the reference itself only on failure;
 * the writer reactor path takes an explicit tcpconn_ref() right before
   calling tcp_queue_write_job() and puts it back only if that fails;
 * the follow-up re-queue in the job completion handler likewise puts
   only on failure.

The queued job releases exactly one reference when it completes, so the
second reference is never matched and leaks. One reference is lost per
send that overlaps an in-flight write job for the same connection.

The consequence is not just memory: with a stray reference held,
tcpconn_destroy() cannot free the connection, because the reaper only
collects at refcnt 0. The connection stays in S_CONN_BAD with
lifetime 0, holding its shm, its fd and a tcp_max_connections slot for
the lifetime of the process.

We observed the accumulation and the climbing refcounts directly, but
did not run a box to exhaustion, so the endpoint is what the code
implies rather than something measured: once enough of these pile up
the proxy reaches tcp_max_connections (default 2048) and refuses every
new TCP, TLS, WS and WSS connection, with the usual 1024 fd soft limit
likely binding first.

Reproduced and diagnosed on a live 4.0 edge proxy with a gdb walk of
the connection table: unreachable connections at refcnt 18, 12, 8, 8
and 2, and a clusterer BIN connection climbing from 3 to 92 references
under a burst of SIP pushes. The leak is transport generic - it also
affects healthy long-lived connections, not only failing ones.

Introduced in 8a9f450df2 ("net: always send messages from main
thread"), so 4.0 and master are affected and 3.x is not.

Co-authored-by: Claude Opus 5 <noreply at anthropic.com>



To unsubscribe from these emails, change your notification settings at https://github.com/OpenSIPS/opensips/settings/notifications