[PATCH] ldb: check result of talloc_get_type in ldb_search_default_callback
Pavel Reichl
preichl at redhat.com
Wed May 13 06:27:08 MDT 2015
On 05/13/2015 02:00 PM, Stefan (metze) Metzmacher wrote:
> Hi Pavel,
>
>> while trying to find out memory leak using talloc_set_name() (which
>> turned out not be a good idea at all) I got segfault from
>> ldb_search_default_callback() caused by dereferencing NULL pointer (res).
>>
>> I understand that returned value of talloc_get_type() is not checked for
>> NULL often and now I'm also aware of problems connected to using
>> talloc_set_name(). However, in my opinion segfault should not happen in
>> any case.
> What values of req->context did you see?
Please correct me if I'm wrong but I think that talloc_get_type() checks
some kind of string type associated with passed pointer to match passed
type and if it doesn't match NULL is returned. However the same field is
changed to whatever I set using talloc_set_name(), which was in my case
something like "%s(%d): %s", __FILE__, __LINE__, __FUNCTION__).
>
> I'd assume talloc_get_type_abort() would the correct thing todo
> as it seems to be a programmer error to fill req->context with something
> unexpected.
>
> BTW: what memory leak are you searching?
In SSSD we have a user having leaked a few hundred thousand of such
allocations in short time:
full talloc report on 'null_context'
struct ldb_result contains 40 bytes in 1 blocks
(ref 0) 0x17c7680
struct ldb_result contains 40 bytes in 1 blocks
(ref 0) 0x17c7540
struct ldb_result contains 40 bytes in 1 blocks
(ref 0) 0x17c7400
struct ldb_result contains 40 bytes in 1 blocks
(ref 0) 0x17e8d30
struct ldb_result contains 40 bytes in 1 blocks
(ref 0) 0x17c5dc0
....
>
> metze
>
More information about the samba-technical
mailing list