One simple stupid users trick owns all your bases ...

[Jeremy Allison]

On Fri, Sep 01, 2023 at 10:15:22AM -0700, Richard Sharpe wrote:
>On Fri, Sep 1, 2023 at 10:04 AM Jeremy Allison <jra at samba.org> wrote:
>>
>> On Fri, Sep 01, 2023 at 09:21:09AM -0700, Richard Sharpe via samba-technical wrote:
>> >Hi folks,
>> >
>> >I didn't follow the instructions carefully enough.
>> >
>> >I set up resolv.conf to point at 127.0.0.1 and an upstream nameserver
>> >(10.20.1.100).
>> >
>> >During provisioning that created an entry of 'dns resolver = 127.0.0.1'.
>> >
>> >That resulted in the following crash. Looks like a bug.
>> >
>> >Provisioning should not use any of the aliases for the current system
>> >as forwarders.
>> >
>> >In addition, perhaps the code should not crash if it gets a timeout.
>> >
>> >4.19.0rc4.
>>
>> Can you add a "panic action = /bin/sleep 99999999"
>> and catch it in gdb. Knowing *exactly* what line
>> it goes down on will help. A lot :-).
>
>OK:
>
>#0  0x00007fa0f256dd98 in nanosleep () from /lib64/libc.so.6
>#1  0x00007fa0f256dc9e in sleep () from /lib64/libc.so.6
>#2  0x00007fa0f8e1c13b in log_stack_trace () at ../../lib/util/fault.c:306
>#3  0x00007fa0f8e1c33f in smb_panic_log (
>    why=why at entry=0x7ffc3acd6050 "Signal 11: Segmentation fault")
>    at ../../lib/util/fault.c:195
>#4  0x00007fa0f8e1c4b3 in smb_panic (
>    why=why at entry=0x7ffc3acd6050 "Signal 11: Segmentation fault")
>    at ../../lib/util/fault.c:206
>#5  0x00007fa0f8e1c619 in fault_report (sig=11) at ../../lib/util/fault.c:83
>#6  sig_fault (sig=11) at ../../lib/util/fault.c:94
>#7  <signal handler called>
>#8  0x00007fa0f7b90049 in dns_cli_request_udp_done (subreq=<optimized out>)
>    at ../../libcli/dns/dns.c:497
>#9  0x00007fa0f7b9134d in dns_udp_request_done (subreq=0x618001b18900)
>    at ../../libcli/dns/dns.c:157
>#10 0x00007fa0f9764929 in tdgram_recvfrom_done (subreq=0x61800533cd00)
>    at ../../lib/tsocket/tsocket.c:239
>#11 0x00007fa0f976b1f7 in tdgram_bsd_recvfrom_handler (
>    private_data=<optimized out>) at ../../lib/tsocket/tsocket_bsd.c:1186
>#12 0x00007fa0f9769c18 in tdgram_bsd_fde_handler (ev=<optimized out>,
>    fde=<optimized out>, flags=<optimized out>, private_data=<optimized out>)
>    at ../../lib/tsocket/tsocket_bsd.c:910
>#13 0x00007fa0f3dc53a7 in tevent_common_invoke_fd_handler ()

tdgram_bsd_recvfrom_recv() calls tsocket_simple_int_recv()
which should set:

         case TEVENT_REQ_TIMED_OUT:
                 *perrno = ETIMEDOUT;
                 return -1;

tdgram_recvfrom_done() looks like:

static void tdgram_recvfrom_done(struct tevent_req *subreq)
{
         struct tevent_req *req = tevent_req_callback_data(subreq,
                                  struct tevent_req);
         struct tdgram_recvfrom_state *state = tevent_req_data(req,
                                               struct tdgram_recvfrom_state);
         ssize_t ret;
         int sys_errno;

         ret = state->ops->recvfrom_recv(subreq, &sys_errno, state,
                                         &state->buf, &state->src);
         if (ret == -1) {
                 tevent_req_error(req, sys_errno);
                 return;
         }

         state->len = ret;

         tevent_req_done(req);
}

state->ops->recvfrom_recv() should be tdgram_bsd_recvfrom_recv()
which should be returning -1 in the ETIMEDOUT Case.

So it should never get to:

lib/tsocket/tsocket.c:239

:-(. Looking under gdb is the next step.