Re: More nsock socket_count_write_dec assert() failures

[David Fifield <david () bamsoftware com>]

On Mon, Jan 25, 2010 at 11:49:19PM -0800, Brandon Enright wrote:
> Some months ago we made some necessary changes to how nsock tracks open
> sockets for reading and writing so we could better control how many
> sockets are open so we didn't corrupt memory when we did a select() on
> them.  Long story short, I think we found properly tracking socket
> states is a lot harder than it sounds.
>
> I have a host that always triggers a:
>
> nmap: nsock_core.c:199: socket_count_write_dec: Assertion `(iod->writesd_count) > 0' failed.
>
> Here are the lines leading up to this:
>
> [...snip...]
> NSE: HTTP: Didn't receive expected response to HEAD request (got 401 Unauthorized).
> NSE: Checking if a GET request is going to work out
> NSE: Final http cache size (597 bytes) of max size of 1000000
> NSE: Finished http-headers against a.b.254.121:443.
> NSE: Final http cache size (615 bytes) of max size of 1000000
> NSE: Final http cache size (633 bytes) of max size of 1000000
> NSE: Root directory requires authentication (401 Unauthorized), scans may not work
> NSE: Total number of pipelined requests: 10
> NSE: Number of requests allowed by pipeline: 1
> NSE Timing: About 92.50% done; ETC: 16:17 (0:00:03 remaining)
> NSE: http-iis-webdav-vuln: PROPFIND request failed.
> NSE: Finished http-iis-webdav-vuln against a.b.254.121:443.
>
>
> Here is a backtrace.  I can recompile Nmap with Lua included so we get
> Lua symbols if that is at all useful.
>
>
> [New process 24011]
> #0  0x00007f0b0163f205 in raise () from /lib/libc.so.6
> (gdb) bt
> #0  0x00007f0b0163f205 in raise () from /lib/libc.so.6
> #1  0x00007f0b01640723 in abort () from /lib/libc.so.6
> #2  0x00007f0b01638229 in __assert_fail () from /lib/libc.so.6
> #3  0x0000000000483bae in socket_count_write_dec (iod=<value optimized out>,
>     ms=<value optimized out>) at nsock_core.c:199
> #4  0x0000000000485cd7 in nsock_loop (nsp=0x25f1ad0, msec_timeout=50)
>     at nsock_core.c:940
> #5  0x00000000004771c1 in l_nsock_loop (L=0x26168a0) at nse_nsock.cc:551
> #6  0x00007f0b0231812b in ?? () from /usr/lib/liblua.so.5
> #7  0x00007f0b02318528 in ?? () from /usr/lib/liblua.so.5
> #8  0x00007f0b023138a6 in lua_call () from /usr/lib/liblua.so.5
> #9  0x0000000000473b2c in nsock_loop (L=0x26168a0) at nse_main.cc:168
> #10 0x00007f0b0231812b in ?? () from /usr/lib/liblua.so.5
> #11 0x00007f0b02322e31 in ?? () from /usr/lib/liblua.so.5
> #12 0x00007f0b02318585 in ?? () from /usr/lib/liblua.so.5
> #13 0x00007f0b02317d27 in ?? () from /usr/lib/liblua.so.5
> #14 0x00007f0b02317da5 in ?? () from /usr/lib/liblua.so.5
> #15 0x00007f0b023136b4 in lua_pcall () from /usr/lib/liblua.so.5
> #16 0x0000000000473931 in run_main (L=0x26168a0) at nse_main.cc:468
> #17 0x00007f0b0231812b in ?? () from /usr/lib/liblua.so.5
> #18 0x00007f0b02318528 in ?? () from /usr/lib/liblua.so.5
> #19 0x00007f0b02317d27 in ?? () from /usr/lib/liblua.so.5
> #20 0x00007f0b02317da5 in ?? () from /usr/lib/liblua.so.5
> #21 0x00007f0b02313657 in lua_cpcall () from /usr/lib/liblua.so.5
> #22 0x0000000000473775 in script_scan (targets=@0x7fff0b18a2a0)
>     at nse_main.cc:607
> #23 0x000000000041fa1e in nmap_main (argc=35, argv=0x7fff0b18d538)
>     at nmap.cc:1894
> #24 0x000000000041af95 in main (argc=35, argv=0x7fff0b18d538) at main.cc:205

It would help if you recompile with debugging and without optimization.
It looks like calls are getting inlined and it's hard to tell where
under nsock_loop the function is being called.

Can you tell if this particular host is being connected to with SSL?

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/