[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