Big apparent memory usage with musl libc when using duplicate-cn with TLS renegotiation (reneg-sec) enabled

Describe the bug
The OpenVPN server process memory usage increases continuously (trend consistent with exponential growth) over approximately 48 hours while the number of connected clients remains stable (~80 clients). The server process becomes unresponsive (management interface stops responding) and must be restarted. No explicit errors appear in the logs prior to loss of responsiveness.

To Reproduce

1. Build and run OpenVPN 2.6.14 on an Alpine Linux 3.21 virtual machine (musl libc), compiled from the official release tarball with compilation options similar to:

   ./configure \
     --enable-lzo \
     --enable-lz4 \
     --enable-plugins \
     --enable-port-share \
     --enable-iproute2
   

   Runtime library versions (per environment banners): OpenSSL 3.3.5, LZO 2.10, LZ4 1.9.x.

2. Server configuration includes (abridged):

   port 1194
   proto udp
   dev tun
   server 172.27.224.0 255.255.240.0
   topology subnet
   
   duplicate-cn
   ifconfig-pool-persist /var/lib/openvpn/ipp.txt
   keepalive 10 120
   reneg-sec 3600
   
   mssfix 1420
   client-to-client
   data-ciphers AES-256-GCM:AES-256-CBC:CHACHA20-POLY1305:AES-128-GCM
   data-ciphers-fallback AES-256-GCM
   auth SHA256
   
   tls-version-min 1.2
   tls-version-max 1.3
   tls-crypt /etc/openvpn/pki/tls-crypt.key
   
   sndbuf 0
   rcvbuf 0
   fast-io
   
   user openvpn
   group openvpn
   persist-key
   persist-tun
   
   verb 3
   management 0.0.0.0 7505
   

   (Startup warning observed: --ifconfig-pool-persist will not work with --duplicate-cn.)

3. Maintain approximately 80 clients connected continuously using the same client certificate (so duplicate-cn is in effect).

4. Monitor the server process memory over time using standard host tools:

   ps -o pid,comm,rss | grep openvpn   # BusyBox ps; RSS in KB
   

   or equivalent host-level monitoring.

5. After ~24–48 hours, observe continuous memory growth (trend consistent with exponential increase) while client count remains steady. The server process becomes unresponsive and requires a restart.

Expected behavior
Server memory usage should remain stable over long uptimes with a steady number of connected clients. Normal client activity (connect/disconnect, TLS handshakes) should not cause unbounded memory growth or loss of responsiveness.

Version information (please complete the following information):

• OS: Alpine Linux 3.21 (musl) running on a virtual machine
• Architecture: aarch64
• OpenVPN version: 2.6.14 (built from official release tarball)
• OpenSSL: 3.3.5
• Peer version (if relevant): OpenVPN 2.6.14
• Transport: UDP

Additional context

• The number of connected clients is stable (~80) during the observation window; the increase in memory is not due to added clients.
• Logs show regular client activity and repeated MULTI: Learn: entries for existing sessions; no explicit errors precede the loss of responsiveness.
• The management interface (bound to 0.0.0.0:7505) becomes non-responsive before the restart.
• The issue reproduces consistently under the conditions described.