Description

A flaw was found in 389-ds-base. The get_ldapmessage_controls_ext() function frees the parsed controls array on the Session Tracking critical-control rejection path without clearing the SLAPI_REQCONTROLS pblock slot. Operation teardown then frees the same pointer again, causing a double-free. An unauthenticated remote attacker can trigger this with a single BIND request carrying a critical Session Tracking control, resulting in heap corruption and potential denial of service.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-12T10:17:18.437Z",
  "pubdate": "2026-08-12T10:17:18.437Z",
  "executiveSummary": "A double-free vulnerability exists in the 389-ds-base directory server, specifically within the handling of LDAP controls. The flaw is triggered via the get_ldapmessage_controls_ext() function when processing the Session Tracking critical-control rejection path. This memory management defect leads to heap corruption and can be leveraged by an unauthenticated remote attacker to cause a denial of service. The vulnerability stems from improper state management within the pblock structure during error handling conditions, allowing a dangling pointer to be processed during operation teardown. Exploitation requires no prior authentication and can be executed remotely using a single crafting BIND request containing a targeted critical Session Tracking control. The risk implication is significant as it directly impacts service availability through application crashes and potential destabilization of the directory service infrastructure. No complex interaction or advanced privileges are required by the threat actor to induce the failure state.",
  "technicalDetails": "The vulnerability resides in the 389-ds-base component, specifically within the get_ldapmessage_controls_ext() function responsible for parsing LDAP message controls. The root cause of the flaw is an inadequate synchronization between memory deallocation and parameter block (pblock) state tracking during exceptional execution paths. When the application evaluates a BIND request carrying a critical Session Tracking control and subsequently encounters a rejection path, get_ldapmessage_controls_ext() frees the memory allocated for the parsed controls array. However, the function fails to nullify or clear the corresponding SLAPI_REQCONTROLS slot within the request's pblock structure.\nAs the execution flow proceeds to the operation teardown phase, the cleanup routines inspect the pblock to ensure all associated resources are properly released. Because the SLAPI_REQCONTROLS slot still retains the memory address of the previously freed controls array, the teardown logic attempts to release the exact same memory pointer a second time. This results in a classic double-free condition within the heap memory allocator. Heap corruption inevitably occurs due to the allocator's internal metadata structures being compromised by redundant deallocation requests for the same memory chunk.\nThe attack vector is network-based and accessible to unauthenticated remote attackers. An attacker initiates exploitation by constructing and transmitting a malicious BIND request over the LDAP protocol to the targeted 389-ds-base server. This payload incorporates a critical Session Tracking control specifically designed to trigger the vulnerable rejection and cleanup logic within get_ldapmessage_controls_ext(). Upon processing the request, the server executes the flawed error-handling branch, sets up the double-free condition, and ultimately faults during operation teardown. The resulting heap corruption leads to an immediate application crash, causing a denial of service for legitimate directory service clients relying on the affected 389-ds-base instance."
}