[OpenSIPS-Devel] [OpenSIPS/opensips] 4d7ed1: aaa_diameter: Fix race condition with async dm_sen...

[Liviu Chircu]

  Branch: refs/heads/3.6
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 4d7ed1d8e8ba077b36c8367ac164df68f2bfca23
      https://github.com/OpenSIPS/opensips/commit/4d7ed1d8e8ba077b36c8367ac164df68f2bfca23
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2026-04-17 (Fri, 17 Apr 2026)

  Changed paths:
    M modules/aaa_diameter/aaa_diameter.c
    M modules/aaa_diameter/dm_impl.c
    M modules/aaa_diameter/dm_impl.h

  Log Message:
  -----------
  aaa_diameter: Fix race condition with async dm_send_request()

- Avoid reading the @dmsg after it has been put on the queue, as it
might get freed meanwhile.

* aaa_diameter: Fix race condition on pending async replies

It was possible for the dm_send_request_async_tout() async timeout
function to ran concurrently with a late Diameter server reply, leading
to a use-after-free bug on the @cond struct.

* Add refcounting to the "cond" object

The SHM-stored @cond object is effectively referenced by two separate
processes/threads, which run concurrently:
    - dm_send_request_async_tout(), the reactor async timeout callback
    - dm_receive_msg(), the libfdcore receiver thread(s)

(cherry picked from commit 01489359c8b528d1cbb5eab1a5c452071a35060a)


  Commit: ae432e1b1cfd3a2d95e2bd4e314244e1f0240f58
      https://github.com/OpenSIPS/opensips/commit/ae432e1b1cfd3a2d95e2bd4e314244e1f0240f58
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2026-04-17 (Fri, 17 Apr 2026)

  Changed paths:
    M lib/cJSON.c
    M modules/aaa_diameter/dm_impl.c

  Log Message:
  -----------
  aaa_diameter: Fix possible PKG/SHM mixup across multiple threads

Despite quite safe at a first glance, the following sequence is actually
NOT safe to use in the modules/aaa_diameter multi-threaded codebase:

    cJSON_InitHooks(&shm_mem_hooks);
    ... perform lib/cJSON.c API operations ...
    cJSON_InitHooks(NULL);

Example: the "diameter-peer" multi-threaded process (35 threads!)
processes two dm_receive_msg() in parallel.  The 1st thread resets the
"shm_mem_hooks" back to PKG using the NULL argument, while the 2nd
thread still assumes they are set to SHM functions, and mixes up memory.

(cherry picked from commit ce2c9642d8727f700133461c26e1a4826ddc303d)


Compare: https://github.com/OpenSIPS/opensips/compare/32c1cba6a14e...ae432e1b1cfd

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