Nmap Development mailing list archives
Re: Adler32 addition to Nbase in r12676 causing rare segfault
From: Daniel Roethlisberger <daniel () roe ch>
Date: Thu, 16 Apr 2009 01:01:17 +0200
Brandon Enright <bmenrigh () ucsd edu> 2009-04-15:
On Wed, 15 Apr 2009 23:32:45 +0200 Daniel Roethlisberger <daniel () roe ch> wrote:Are you sure this isn't actually a segmentation fault in zlib's adler32(), and gdb is messing up the namespace, using the debug information and/or source code for adler32() in nbase?It isn't GDB, it seems the linker resolved the symbol wrong (your hypothesis below is correct).Nbase adler32() is not called from anywhere at the moment in trunk, and I'd be rather surprised if your rtld would somehow cause deflate() in libz.so.1 to call nbase adler32() instead of zlib's internal adler32().Looks like that is what is happening.ssl3_do_uncompress () from /usr/lib/libssl.so.0.9.8 #5 0x00007f230b158470 in ssl3_read_bytes ()The len field looks like the high dword of a 64 bit pointer, probably pointing to the heap. This could equally be either gdb misinterpreting things based on the wrong source code, or code compiled against the signature of zlib adler32() actually calling nbase adler32().Yeah, it is calling the nbase adler32 which I'm sure has a different set of parameters/API than yours.Unless someone can reproduce these segfaults, I don't think I can fix this without some debugging / verification help from you. Can you add an assert(0) on the first line of nbase adler32() to make sure that our adler32() is not called when your segfaults happen?$ sudo ./nmap -A -v -p 465 -T5 -PN -n -d <target> Starting Nmap 4.85BETA7 ( http://nmap.org ) at 2009-04-15 21:47 UTC --------------- Timing report --------------- hostgroups: min 1, max 100000 rtt-timeouts: init 250, min 50, max 300 max-scan-delay: TCP 5, UDP 1000 parallelism: min 0, max 0 max-retries: 2, host-timeout: 900000 min-rate: 0, max-rate: 0 --------------------------------------------- NSE: Loaded 27 scripts for scanning. Initiating SYN Stealth Scan at 21:47 <snip> Completed SYN Stealth Scan at 21:47, 0.01s elapsed (1 total ports) Overall sending rates: 190.73 packets / s, 8392.14 bytes / s. Initiating Service scan at 21:47 Scanning 1 service on 132.239.51.80 nmap: nbase_misc.c:469: adler32: Assertion `0' failed. Aborted (core dumped) So the question is, why did the linker resolve to your adler32() routine rather than zlib? Is there a way we can fix this across all compilers/platforms or should we just rename your adler32() routine to nbase_adler32()?
The nbase_ prefix was my first idea as well, but I'd propose to change the names of all of the checksumming functions (crc32, crc32c, adler32). A gut feeling tells that this cannot be resolved in a different way which would also be portable and hassle-free, but I am by no means a shared library and rtld expert. -- Daniel Roethlisberger http://daniel.roe.ch/ _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Adler32 addition to Nbase in r12676 causing rare segfault Brandon Enright (Apr 15)
- Re: Adler32 addition to Nbase in r12676 causing rare segfault Daniel Roethlisberger (Apr 15)
- Re: Adler32 addition to Nbase in r12676 causing rare segfault Brandon Enright (Apr 15)
- Re: Adler32 addition to Nbase in r12676 causing rare segfault Daniel Roethlisberger (Apr 15)
- Re: Adler32 addition to Nbase in r12676 causing rare segfault Fyodor (Apr 15)
- Re: Adler32 addition to Nbase in r12676 causing rare segfault Daniel Roethlisberger (Apr 16)
- Re: Adler32 addition to Nbase in r12676 causing rare segfault Brandon Enright (Apr 15)
- Re: Adler32 addition to Nbase in r12676 causing rare segfault Daniel Roethlisberger (Apr 15)