Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ncat segfault in __strlen_avx2 () from /usr/lib64/haswell/libc.so.6 #2154

Closed
bswinnerton opened this issue Oct 15, 2020 · 10 comments
Closed

ncat segfault in __strlen_avx2 () from /usr/lib64/haswell/libc.so.6 #2154

bswinnerton opened this issue Oct 15, 2020 · 10 comments
Assignees
@nnposter
Labels
bug Ncat

Comments

@bswinnerton
Copy link

Describe the bug
When invoking ncat over a Unix socket (for example with nc -U /var/run/libvirt/libvirt-sock), the application segfaults

To Reproduce

$ touch /tmp/foo
$ nc -U /tmp/foo
Segmentation fault (core dumped)

Expected behavior
In the example above, the expected behavior is:

$ touch /tmp/foo
$ nc -U /tmp/foo
Ncat: Connection refused.

Version info (please complete the following information):

  • OS: 5.8.14-991.native
  • Output of ncat --version: Ncat: Version 7.91 ( https://nmap.org/ncat )

Additional context

To quote clearlinux/distribution#2152 (comment):

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7d89db5 in __strlen_avx2 () from /usr/lib64/haswell/libc.so.6
(gdb) bt
#0  0x00007ffff7d89db5 in __strlen_avx2 () from /usr/lib64/haswell/libc.so.6
#1  0x00007ffff7c981f4 in __GI___strdup (s=0x0) at strdup.c:41
#2  0x000055555555fcd8 in nsock_iod_set_hostname (hostname=0x0, iod=0x5555555da270) at ../nsock/src/nsock_iod.c:453
#3  new_iod (mypool=<optimized out>) at ncat_connect.c:907
#4  0x000055555555d535 in ncat_connect () at ncat_connect.c:1018
#5  ncat_connect_mode () at ncat_main.c:1020
#6  main (argc=<optimized out>, argv=<optimized out>) at ncat_main.c:997
(gdb) f 3
#2  0x000055555555fcd8 in nsock_iod_set_hostname (hostname=0x0, iod=0x5555555da270) at ../nsock/src/nsock_iod.c:453
   if (nsock_iod_set_hostname(nsi, o.sslservername) == -1)
(gdb) p o
$1 = {portno = 31337, verbose = 0, debug = 0, target = 0x7fffffffe6e6 "/tmp/foo", af = 1, proto = 6, broker = 0, listen = 0, keepopen = 0, 
  sendonly = 0, recvonly = 0, noshutdown = 0, telnet = 0, linedelay = 0, chat = 0, nodns = 0, normlog = 0x0, hexlog = 0x0, normlogfd = -1, 
  hexlogfd = -1, append = 0, idletimeout = 0, crlf = 0, allow = 0, deny = 0, allowset = 0x5555555d9870, denyset = 0x5555555d9910, 
  httpserver = 0, nsock_engine = 0, test = 0, srcrtes = {{s_addr = 0}, {s_addr = 0}, {s_addr = 0}, {s_addr = 0}, {s_addr = 0}, {s_addr = 0}, {
      s_addr = 0}, {s_addr = 0}}, numsrcrtes = 0, srcrteptr = 4, conn_limit = -1, conntimeout = 10000, cmdexec = 0x0, execmode = EXEC_PLAIN, 
  proxy_auth = 0x0, proxytype = 0x0, proxyaddr = 0x0, proxydns = 2, ssl = 0, sslcert = 0x0, sslkey = 0x0, sslverify = 0, ssltrustfile = 0x0, 
  sslciphers = 0x0, sslservername = 0x0, sslalpn = 0x0, zerobyte = 0}

o.sslservername is set to NULL at

nmap/ncat/ncat_core.c

Line 152 in ef8213a

o.sslservername = NULL;
and set to something different at

nmap/ncat/ncat_main.c

Line 511 in ef8213a

o.sslservername = Strdup(optarg);

But this is not an SSL connection so it's not expected to be set to anything but null.

As mentioned by @thiagomacieira, the bug was introduced in 7d6cf3a which introduced o.sslservername, but that's only for TCP connections, not unix sockets.

/cc @nnposter as you may have context
/cc clearlinux/distribution#2152
@bswinnerton bswinnerton mentioned this issue Oct 15, 2020
Closed
@nnposter nnposter added the bug label Oct 15, 2020
@nnposter nnposter self-assigned this Oct 15, 2020
@nnposter
Copy link

Could you please test the following patch and report back?

--- a/ncat/ncat_main.c	2020-10-07 17:21:42.253789857 -0600
+++ b/ncat/ncat_main.c	2020-10-14 21:37:31.527610020 -0600
@@ -846,7 +846,7 @@
             targetaddrs->addr.un.sun_family = AF_UNIX;
             strncpy(targetaddrs->addr.un.sun_path, argv[optind], sizeof(targetaddrs->addr.un.sun_path));
             targetaddrs->addrlen = SUN_LEN(&targetaddrs->addr.un);
-            o.target = argv[optind];
+            o.sslservername = o.target = argv[optind];
             optind++;
         } else
 #endif
@@ -865,7 +865,7 @@
                 targetaddrs->addr.vm.svm_cid = long_cid;
 
                 targetaddrs->addrlen = sizeof(targetaddrs->addr.vm);
-                o.target = argv[optind];
+                o.sslservername = o.target = argv[optind];
                 optind++;
             }
         } else

@thiagomacieira
Copy link

Confirmed

$ /tmp/usr/bin/ncat -U /tmp/foo
Ncat: No such file or directory.
$ touch /tmp/foo
$ /tmp/usr/bin/ncat -U /tmp/foo
Ncat: Connection refused.

@nnposter
Copy link

The patch has been committed as r38121. Thank you for reporting the issue and pin-pointing the offending commit; my bad.

@thiagomacieira
Copy link

I'll apply the committed patch to Clear tomorrow.

@sergio-correia sergio-correia mentioned this issue Nov 15, 2020
Closed
@nnposter nnposter mentioned this issue Mar 10, 2021
Closed
@nnposter nnposter mentioned this issue Jul 14, 2021
Closed
@stilor
Copy link

stilor commented Jul 19, 2021

@nnposter Can the fix be backported to the 7.9x release branch, please?

@nnposter
Copy link

I am not quite sure what specifically you are asking for. The patch above (f6b4061) can be certainly applied to 7.91 source code and there should be no dependencies on other changes introduced after 7.91. The traditional backporting (i.e. patching the old source code, recompiling, and releasing new packages) could be done by the various distro maintainers, not by Nmap maintainers. I am confident that the next Nmap release will include the fix as well, as this is a straightforward bug fix.

@stilor
Copy link

stilor commented Jul 20, 2021

I was talking about applying that patch to the 7.90 release branch: https://svn.nmap.org/nmap-releases/nmap-7.90/; the 7.91 release has been created from that branch.

Otherwise if the next release of nmap (7.92) is created from that branch, it will not include this fix. At least one fix has already been backported to that branch after 7.91 release (r38105, "fix the windows timestamp/timezone problem"), so I assume another 7.9x release from that branch is possible.

@fyodor
Copy link
Member

fyodor commented Aug 15, 2021

I'm closing this since I believe it has been fixed in Nmap version 7.92. Please post if you are still experiencing the problem with 7.92.

@dmiller-nmap
Copy link

@stilor The branches in nmap-releases are public for convenience, but not used in a strict release-branch workflow. We branched the 7.92 release off of the main trunk, for instance.

mtremer pushed a commit to ipfire/ipfire-2.x that referenced this issue Sep 5, 2021
ncat: Update to 7.91 and fix #12647 ncat segfault if virtmanager try …
999b71c 
…to connect libvirt

- Update from 7.80 to 7.91
- Update of rootfile
- Changelog is too long to include here
   Full details can be found in the CHANGELOG file in the source tarball
- Added patch to fix segfault - nmap/nmap#2154
- Ran with unpatched 7.91 version
   $ touch /tmp/foo
   $ nc -U /tmp/foo
   Segmentation fault - flagged problem in #12647
- Ran with patched 7.91 version
   $ touch /tmp/foo
   $ nc -U /tmp/foo
   Ncat: Connection refused. - Expected behaviour

Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
@dotted dotted mentioned this issue Aug 7, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nnposter nnposter

Labels
bug Ncat
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@bswinnerton @fyodor @thiagomacieira @nnposter @dmiller-nmap @stilor and others