ASSERT crash/failure in client code with an error assert(session->side == NC_CLIENT) in function nc_session_client_msgs_unlock

[late-pankaj]

The client application is encountering an ASSERT failure within the libnetconf2 library, specifically in nc_session_client_msgs_unlock.

Sequence of Events Leading to Crash:

1.Normal Operation: The client application's NETCONF connection is initially working as expected.
2.Connection Instability/Breakdown: The connection experiences an issue , leading to a disconnect or an unstable state .
Concurrent Activities Within libnetconf2:

Session Cleanup: Recognizing the connection issue, client initiates a session disconnect/free operation, which calls nc_session_free .

During this process, attempts to acquire the msgs_lock but fails because another internal thread(rcv_reply) is holding it. This results in the libnetconf2 error log:

"Freeing a session while messages are being received."

Despite failing to acquire the msgs_lock for the message queue, nc_session object, potentially including the session structure's memory itself.

Concurrently, rcv_reply is still actively processing messages for the same session. This thread had previously acquired the msgs_lock (preventing nc_session_free from acquiring it). It receives a delayed rpc-reply message (e.g., message-id="12") from the network.

Received message: <data ...>

Crash - Use-After-Free: After processing the message, rcv_reply attempts to release the msgs_lock by calling nc_session_client_msgs_unlock. However, the session object it's operating on has already been partially or fully freed/invalidated. When nc_session_client_msgs_unlock tries to access session->side to verify its state, the value is no longer NC_CLIENT (as the memory might be corrupted or reallocated).

This triggers the assertion:
.../libnetconf2-workspace/src/session.c:442: nc_session_client_msgs_unlock: Assertion `session->side == NC_CLIENT' failed.

assert(session->side == NC_CLIENT);

The client process then terminates with SIGABRT (signal 6).

Root Cause:
This is a critical race condition leading to a use-after-free scenario . The library's internal session management fails to correctly synchronize its own threads when one thread is actively receiving messages for a session while another is attempting to free that same session. The existing msgs_lock only protects the message queue itself, but not the entire nc_session structure's integrity during a concurrent free operation, leading to operations on an invalid session pointer.

Let me know if my analysis is wrong or missing any key understanding or reference .

[michalvasko]

You are using libnetconf2 in your own server, right? I believe the library should not free any sessions on its own and the synchronization is left up to the user, the library cannot implement this, anyway.

[late-pankaj]

Got it ,But during race condition
we should better avoid ASSERT