Issue 10135 - dynlist (and maybe others) doesn't use the right overinst context in callbacks
Summary: dynlist (and maybe others) doesn't use the right overinst context in callbacks
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: overlays (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: 2.5.17
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-23 12:17 UTC by Ondřej Kuzník
Modified: 2024-01-29 20:38 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Ondřej Kuzník 2023-11-23 12:17:22 UTC
Running the test suite with `-fsanitize=address` picks up a bug in https://git.openldap.org/openldap/openldap/-/blob/860b61f41dfeeb19cc0eb011f290561c68a13de3/servers/slapd/overlays/dynlist.c#L1681

Here, op->o_bd->bd_info isn't actually dynlist but mdb's own static bi, so overlay_entry_get_ov then reaches into the void when reading on->on_info.

It's very likely that other places/overlays share the same bug as it is subtle and doesn't get picked up immediately (slap_overinst embeds a BackendInfo and oi_orig is not often set).
Comment 1 Ondřej Kuzník 2024-01-05 13:40:32 UTC
Trying to deal with this, dynlist is deeply married to using op->o_bd->bd_info in places that could be coming from a callback (dynlist_nested_member, ...). I can't see a clear way to disentagle this myself.

Howard, do you want to take this on?
Comment 3 Quanah Gibson-Mount 2024-01-16 20:38:45 UTC
head:

  • b3eab2ce 
by Howard Chu at 2024-01-10T19:33:38+00:00 
ITS#10135 dynlist: fix search2resp callback context
Comment 4 Quanah Gibson-Mount 2024-01-16 20:54:17 UTC
RE26:

  • ffdd12f0 
by Howard Chu at 2024-01-16T20:38:57+00:00 
ITS#10135 dynlist: fix search2resp callback context

RE25:

  • a4026502 
by Howard Chu at 2024-01-16T20:39:11+00:00 
ITS#10135 dynlist: fix search2resp callback context
Comment 5 Quanah Gibson-Mount 2024-01-17 15:59:24 UTC
*** Issue 10044 has been marked as a duplicate of this issue. ***