crash in connections_fetch_entry when yielding connection after share deleted ...

[Richard Sharpe]

On Wed, May 23, 2012 at 3:38 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> Hi folks,
>
> I have the following panic in one of our logs:
>
> [2012/05/23 11:27:05.271238,  1] smbd/service.c:1248(close_cnum)
>  10.250.201.175 (10.250.201.175) closed connection to service (null)
> [2012/05/23 11:27:05.300076,  0] lib/fault.c:46(fault_report)
>  ===============================================================
> [2012/05/23 11:27:05.300146,  0] lib/fault.c:47(fault_report)
>  INTERNAL ERROR: Signal 11 in pid 29753 (3.5.15-ACL-FIX)
>  Please read the Trouble-Shooting section of the Samba3-HOWTO
> [2012/05/23 11:27:05.300209,  0] lib/fault.c:49(fault_report)
>
>  From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
> [2012/05/23 11:27:05.300267,  0] lib/fault.c:50(fault_report)
>  ===============================================================
> [2012/05/23 11:27:05.300308,  0] lib/util.c:1468(smb_panic)
>  PANIC (pid 29753): internal error
> [2012/05/23 11:27:05.352921,  0] lib/util.c:1572(log_stack_trace)
>  BACKTRACE: 25 stack frames:
>   #0 smbd(log_stack_trace+0x1c) [0x2af1c4fedcc1]
>   #1 smbd(smb_panic+0xa5) [0x2af1c4feda9c]
>   #2 smbd [0x2af1c4fd29ea]
>   #3 smbd [0x2af1c4fd29fd]
>   #4 /lib64/libc.so.6 [0x2af1c8aaf2d0]
>   #5 smbd(rep_strlcpy+0x29) [0x2af1c4f9aa7f]
>   #6 smbd(connections_fetch_entry+0x94) [0x2af1c5003629]
>   #7 smbd(yield_connection+0xbc) [0x2af1c4c0b276]
>   #8 smbd(close_cnum+0x220) [0x2af1c4cc6cc1]
>   #9 smbd(conn_close_all+0x53) [0x2af1c4c17bc4]
>
> The code in lib/conn_tdb.c:connections_fetch_record is getting passed
> NULL (as shown above in the debug line about closed connection to
> service (null), It is crashing here:
>
>        strlcpy(ckey.name, name, sizeof(ckey.name));
>
> because name is NULL.
>
> I suggest we simply return without doing anything in that case. I
> suspect it happens in rare cases when a client is connected and the
> share is ripped out from underneath them, and then they close the
> connection or disconnect.

Here is a potential fix for this problem:

diff --git a/source3/lib/conn_tdb.c b/source3/lib/conn_tdb.c
index 9b0a07a..dc1d8c1 100644
--- a/source3/lib/conn_tdb.c
+++ b/source3/lib/conn_tdb.c
@@ -60,6 +60,10 @@ struct db_record *connections_fetch_entry(TALLOC_CTX *mem_ctx
        struct connections_key ckey;
        TDB_DATA key;

+       if (name == NULL) {
+               return NULL;
+       }
+
        ZERO_STRUCT(ckey);
        ckey.pid = messaging_server_id(conn->sconn->msg_ctx);
        ckey.cnum = conn->cnum;


-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)