Segmentation fault with IPv6 loopback but no other IPv6 interface

[drscream]

We detected a strange behavior (segmentation fault) if an IPv4 and IPv6 loopback device is on an SmartOS zone. This will only happen if a IPv4 address is set but no IPv6 is configured and IPv6 loopback interface is present.

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
    inet 127.0.0.1 netmask ff000000 
net0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
    inet 80.190.131.157 netmask ffffff80 broadcast 80.190.131.255
    ether 22:8:3:8c:c4:c4 
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
    inet6 ::1/128 

It gets stuck in the loop https://github.com/postwait/node-ife/blob/master/arpcache-dlpi.cc#L128-L130 because ip->ipNetToMediaEntrySize is 0. The workaround is to setup a real IPv6 interface with an valid address (or unplumb the v6 loopback).

I'm not sure if it's a illumos bug, because req->level might be 0x104 for the IPv6 loopback.

[postwait]

Try the latest commit.

[drscream]

This returns an empty arp cache but doesn't crash anymore. But entries are visible with arp -a.

[postwait]

You're likely in a better position to debug this than me. Care to fix and submit a pull request?

[drscream]

I've looked at the code for around 4 hours but couldn't find any mistake. I've also checked the source from netstat and the code didn't look so different. Also netstat doesn't have a check for ip->ipNetToMediaEntrySize == 0.

I've also verified the code on OmniOS and it's reproducible there too.