Zerotier-cli shows 'Segmentation fault' on version 1.6.0

I just upgraded to zerotier-one from version 1.4.6 to 1.6.0 running on Pop_OS on my laptop. Since then I get an ‘Segmentation fault’ when I invoke ‘zerotier-cli’, no matter what parameter I use. I have re-started the zerotier-one daemon process a few times, rebooted a few times, but the problem persists, get a ‘Segmentation fault’ whenever I run zerotier-cli .
However, zerotier itself seems to be working. All routes are set as expected and ping’s between the machines work.
Any ideas?

Just updated Zerotier on my Pop-OS 20.10. Works fine.

I am on Pop_OS 20.04 LTS and really don’t want to upgrade the OS just now.

Pop-OS 20.10 works really well and solved a lot of problems around scaling.

I just updated Zerotier on one of my Ubuntu 20.04 containers at got Segmentation faults and also had strange issues on Windows, better roll back and wait for another release. You can find the older release here:

Thanks for the hint. I better get back to 1.4.6 then too.

I’m having this issue on my Fedora 33 Laptop and it’s not even connecting to the network, but on my Centos 8 Server upgraded just fine.

Yep i have the same results, on EL and Fedora based systems it look like a SELinux issue, if you have SELinux enabled it wil segfault. Maybe the same issue happen on Ubuntu based Systems with AppArmor.

LXC containers by default drop some cgroup caps that your container will need to zerotier.

echo -e "lxc.cap.drop=" | lxc config set mycontainer raw.lxc -
lxc restart mycontainer

Additionally on Ubuntu 20.04 I don’t get an IP address when starting 1.6.0. I also see the segmentation fault when I run zerotier-cli as user, but not as root.

I have hit this on my CentOS 8 system as well. I get the following SELinux denial:

type=AVC msg=audit(1606126059.434:83): avc:  denied  { mmap_zero } for  pid=2009 comm="zerotier-one" scontext=system_u:system_r:unconfined_service_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=memprotect permissive=0

For which I am suggested the following by audit2why:

	The boolean mmap_low_allowed was set incorrectly. 
	Control the ability to mmap a low area of the address space, as configured by /proc/sys/vm/mmap_min_addr.

	Allow access by executing:
	# setsebool -P mmap_low_allowed 1

Enabling that SELinux boolean made SIGSEGVs disappear.

It seems that this SELinux boolean default 0 value prevents a process from mmapping a virtual address lower than /proc/sys/vm/mmap_min_addr (which is 4096 in my CentOS system) for security reasons. So maybe the reason behind this is something trying to mmap a too low virtual address.

Regarding non-CentOS or non-Fedora operating systems, not sure if AppArmor can set a similar restriction.

1 Like

I have this same issue on CentOS Linux release 7.9.2009 (Core), in my case the VM is running on OpenVZ so I have no access to setsebool and there is no apparent selinux running in the VM. For 1.4.6 I have to run as root (/usr/sbin/zerotier-one -U) to get it to find the tun module.

segmentation fault on Ubuntu Groovy Desktop after fresh installation of ZeroTier.


$sudo apt remove zerotier-one
$cat /etc/apt/preferences.d/zerotier-one 
Package: zerotier-one
Pin: version 1.4.6*
Pin-Priority: 1001
$sudo apt update
$sudo apt install zerotier-one

Happening to me. Fresh Ubuntu 20 install, it is not creating the ZT interface and, thus, no IP.

apt install zerotier-one=1.4.6 to downgrade until the next release

Did that, restarted ZeroTier, still not interface. Restarted VM, still the same. Is there some type of clean up required as well?

My issue was the node wasn’t joined to any network (duh!). All working fine now.

1.6.1 doesn’t fix the problem, for me.

@mrvanes you’re going to have to be more specific on what exactly your issue is. I can’t get it to segfault on Ubuntu no matter how hard I try. If you’re not getting a segfault, then you should be creating a new thread because it isn’t the same issue.

1.6.1 packages for Linux are now out and should fix all the Seg Fault issues.

I confirm that the issue is no longer reproducible for me on both Centos8 and Fedora33. I could set mmap_low_allowed SELinux boolean back to its default value 0 and I have no denials.


1 Like