Memory corruption issue when samba4 is the target of a net vampire command

[Matthias Dieter Wallnöfer]

Well, I guess that the problem lies in the "service_task.c". The 
function "task_server_startup" should probably prevent the invocation of 
"task_server_terminate" when it enters an error branch.
But since I don't understand much of this code I would really like to 
hear an opinion from the original authors of this service helper library.

Greets,
Matthias

Angelos Oikonomopoulos wrote:
> On 10/27/2010 09:58 AM, Andrew Bartlett wrote:
>> On Wed, 2010-10-27 at 18:52 +1100, Andrew Bartlett wrote:
>>> On Tue, 2010-10-26 at 17:23 +0200, Angelos Oikonomopoulos wrote:
>>>> Hello all,
>>>>
>>>> I've been playing around with Samba 4 from git master (specifically
>>>> 5785f08268bac332d09bdf71d1907ecb54f3b5bd from last Thursday). It seems
>>>> to work well so far, but I've run into a bug when trying to add a 
>>>> second
>>>> samba4 server as an additional DC, following the instructions in
>>>> http://wiki.samba.org/index.php/Samba4/HOWTO/Join_a_domain_as_a_DC.
>>>>
>>>> Specifically, the net vampire command described in that page 
>>>> crashes the
>>>> existing DC pretty reliably. I've tried looking into it today but I
>>>> think I'll need some help to track down the root cause (and produce 
>>>> a fix).
>>>
>>> If this is reproducible, then put printf() statements in near every
>>> questionable variable.  valgrind will then complain when you print
>>> invalid things, now that it knows you expected it to be valid NOW,
>>> rather than later.
>>>
>>> I don't see from what you have sent why the task would not be 
>>> valid.  It
>>> is passed in to the socket code at the top level, and ends up being
>>> passed to the accept handler.
>>
>> Also, liberal addition of talloc_get_type_abort() is often a quick way
>> to assert that pointers are current, valid memory.
>
> Thank you for your help. The use-after-free is real:
>
> ===661== Invalid read of size 8
> ==661==    at 0x8637922: ldapsrv_accept_nonpriv (ldap_server.c:757)
> ==661==    by 0x853FEE8: stream_new_connection (service_stream.c:230)
> ==661==    by 0x8511873: single_accept_connection (process_single.c:74)
> ==661==    by 0x853FF5D: stream_accept_handler (service_stream.c:245)
> ==661==    by 0x8D3479B: epoll_event_loop (tevent_standard.c:310)
> ==661==    by 0x8D34F11: std_event_loop_once (tevent_standard.c:545)
> ==661==    by 0x8D30B11: _tevent_loop_once (tevent.c:493)
> ==661==    by 0x8D30D4E: tevent_common_loop_wait (tevent.c:594)
> ==661==    by 0x8D30E19: _tevent_loop_wait (tevent.c:613)
> ==661==    by 0x404D7B: binary_smbd_main (server.c:480)
> ==661==    by 0x404DC1: main (server.c:491)
> ==661==  Address 0x199190b8 is 104 bytes inside a block of size 136 
> free'd
> ==661==    at 0x4C240FD: free (vg_replace_malloc.c:366)
> ==661==    by 0x99D6C17: _talloc_free_internal (talloc.c:669)
> ==661==    by 0x99D7C16: _talloc_free (talloc.c:1141)
> ==661==    by 0x8540FE3: task_server_terminate (service_task.c:52)
> ==661==    by 0x863827C: ldapsrv_task_init (ldap_server.c:985)
> ==661==    by 0x8541103: task_server_callback (service_task.c:90)
> ==661==    by 0x85118F9: single_new_task (process_single.c:95)
> ==661==    by 0x85411A1: task_server_startup (service_task.c:110)
> ==661==    by 0x853F609: server_service_init (service.c:63)
> ==661==    by 0x853F727: server_service_startup (service.c:95)
> ==661==    by 0x404CFF: binary_smbd_main (server.c:471)
> ==661==    by 0x404DC1: main (server.c:491)
>
> with:
> epoll_event_loop: fde=0x1a055180, priv=0x1a032090
> c=0x147dfee0, ldapsrv_service=0x19ef3060, task=0x199190a0, 
> lp_ctx=(nil), &session_info=0x7ff000560
> Terminating connection - 'failed to setup anonymous session info'
> single_terminate: reason[failed to setup anonymous session info]
>
> But it only happens on an error path. Specifically, I had done a chown 
> on private/ that prevented the ldap server from starting and that 
> caused samba to die in an unfriendly way :) After lots of tracing I 
> eventually tracked down the problem and only then found the ldap 
> termination message which had been lost in all the debug output :)
>
> After this, the net vampire command worked successfully. Replication 
> works as expected and the combination of the two DCs seems to be 
> pretty robust in the face of arbitrary kills. Tomorrow I'll take a 
> look and see if I there's an easy way to avoid the use-after-free in 
> this case so that samba will die in a less mysterious way if the ldap 
> server can't start.
>
> Again, thanks for your time,
> Aggelos
>