https://bugs.openldap.org/show_bug.cgi?id=10663
Issue ID: 10663 Summary: syncprov: double free of sync controls since ITS#10473 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: hamano@osstech.co.jp Target Milestone: ---
The fix for this ticket (RE26: 7d9b599982, master: 87197f91fc) causes the sync state controls to be freed twice in OpenLDAP 2.6.14 and later, and in master.
## Details
Three of the four callers of `syncprov_state_ctrl()` / `syncprov_done_ctrl()` have set `REP_CTRLS_MUSTBEFREED` since ITS#6795 and ITS#7292, so the frontend (`send_ldap_response()` / `slap_send_search_entry()` / `slap_send_search_reference()`) already frees each control individually with `slap_free_ctrls()` after `slap_cleanup_play()`.
With this fix, the control lives in the same allocation as a `slap_callback`. After `slap_freeself_cb` has freed the callback (and the control with it), `slap_free_ctrls()` passes a pointer into the middle of the freed callback (`&cb[1]`) to `o_tmpfree()` again.
The only leak in the original report is the `no_change:` path, which uses a controls array on the stack and does not set `REP_CTRLS_MUSTBEFREED`. Also, `slap_add_ctrls()` copies the pointers of an existing `sr_ctrls` into a new array and sets `REP_CTRLS_MUSTBEFREED`, so `slap_free_ctrls()` relies on each control being allocated on its own. Embedding the control in a callback is not compatible with that.
## Impact
When the allocation did not fit in the slab and fell back to `ber_memalloc_x()` (for example a long replay of a persistent search, or a refresh of large entries), or when `o_tmpmemctx` is NULL, the interior pointer reaches libc `free()` and the provider slapd aborts with `free(): invalid pointer`.
## Proposed fix
1. Revert this fix (87197f91fc / 7d9b599982) so that the control is allocated on its own again, as before. 2. In the `no_change:` path, free the control after `send_ldap_result()`.
https://bugs.openldap.org/show_bug.cgi?id=10663
--- Comment #1 from HAMANO Tsukasa hamano@osstech.co.jp --- https://git.openldap.org/openldap/openldap/-/merge_requests/953