Re: Assertion failure in nsock_core

[Andrew Whatson <whatson () gmail com>]

On Tue, Jul 14, 2009 at 4:49 AM, David Fifield<david () bamsoftware com> wrote:
> On Tue, Jul 14, 2009 at 01:52:47AM +1000, Andrew Whatson wrote:
> > I seem to be getting an error when performing any scan with nmap
> > compiled off the latest svn (r14230).
> >
> > The hosts on .1 and .2 are definitely up and ping fine - this seems to
> > be a bug introduced in Monday's commits.
> >
> > I'm running ubuntu 2.6.31-2-generic x86_64 (karmic).
> >
> > ==========
> > # nmap -v -sP 192.168.1.*
> >
> > Starting Nmap 4.90RC2 ( http://nmap.org ) at 2009-07-14 01:41 EST
> > NSE: Loaded 0 scripts for scanning.
> > Initiating ARP Ping Scan at 01:41
> > Scanning 3 hosts [1 port/host]
> > Completed ARP Ping Scan at 01:41, 0.23s elapsed (3 total hosts)
> > Host 192.168.1.0 is down.
> > Host 192.168.1.1 is down.
> > Host 192.168.1.2 is down.
> > Initiating Parallel DNS resolution of 1 host. at 01:41
> > nmap: nsock_core.c:139: socket_count_zero: Assertion
> > `iod->events_pending == 1' failed.
> > Aborted
> > ==========
>
> Thanks for the report. This is fixed in r14235. Please try it. The ping
> failure is a separate issue; please tell us if it persists.

Thanks for the fix!  I've compiled r14252 and everything is working as
expected, including pinging those hosts.

> This is a really interesting assertion failure, because it was both
> detected and prevented from doing any harm by the removal of several
> other bugs.
>
> The underlying problem that the assertion is complaining about is that
> an attempt was made to clear the select sets while there were read or
> write events pending. (The assertion expects only one event--the connect
> event--in this case there was additionally a read and write event.) If
> the select sets are cleared, then read and write events will never get
> notified and handled. I added the assertion when I added the
> socket_count code; the code that was there before would have ignored the
> problem.
>
> Bug #1 was "Ncat with SSL using 100% CPU," fixed with the socket_count
> code and incidentally featuring the assertion.
> http://seclists.org/nmap-dev/2009/q2/0729.html
>
> Nmap's reverse DNS code is what was queueing read and write events
> before the first connect finished. This was not a bug; the bug was in
> handle_connect_result that didn't account for already queued events. Why
> wasn't this a problem before? Because until yesterday,
> handle_connect_result was not called for connections that succeeded
> immediately, which includes UDP "connections." Special-case code simply
> discarded the event immediately, which turns out to not to work for
> localhost SSL connections on FreeBSD 7.2, which is why it was changed.
>
> Bug #2 was "Localhost Nsock SSL connections unencrypted on FreeBSD,"
> which was really about handle_connect_result not being called for
> immediately successful connections.
> http://seclists.org/nmap-dev/2009/q3/0116.html
>
> Bug #3 was simply that handle_connect_result did not properly handle
> connections where reads and writes were already queued; this is fixed in
> r14235.
> http://seclists.org/nmap-dev/2009/q3/0128.html
>
> David Fifield

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