dhcpcd-discuss

On 07/03/2017 20:57, Shahid Mahmood wrote:
> Hi Roy,
> There is a crash found during restart of dhcpcd. Brief bt:
> ...
> 
>     Core was generated by `dhcpcd -4 -f /var/run/dhcp/dhcpcd.conf -c
>     /bin/dhcpcd-run-hooks --l'.
>     Program terminated with signal SIGSEGV, Segmentation fault.
>     ...
> 
>     #0  0x3d737264 in ?? ()
>     #1  0x0001e0d4 in arp_packet (len=<optimized out>, data=0xbee65938 "",
>         ifp=<optimized out>) at arp.c:180
>     #2  arp_read (arg=0xfdc108) at arp.c:206
>     #3  0x00010148 in eloop_start (eloop=0xfdbdc8, signals=0xbee65a70,
>         signals@entry=0xbee65a68) at eloop.c:969
>     #4  0x0000aff0 in main (argc=<optimized out>, argv=<optimized out>)
>         at dhcpcd.c:1940
> 
>     # dhcpcd --version
>     dhcpcd 6.11.5
>     Copyright (c) 2006-2016 Roy Marples
>     Compiled in features: INET IPv4LL INET6 DHCPv6 AUTH
> 
> Detailed bt attached, as well as dhcpcd.conf. I am trying to reproduce
> the crash but not too hopeful if it will occur again.
> 
> Let me know if you need any more info.

OK, I tracked this down after giving the Solaris port some loving.

Because of the BPF API on BSD and Solaris, we need to read the whole BPF
buffer from the kernel and process that packet by packet. Linux doesn't
have this limitation but has to have the same processing loop in dhcp.c
and arp.c.

The actual issue is that during packet processing, the state could be
freed at any time. But this is not being checked before trying to read
the next packet.

The reason why this hasn't been seen by myself until now is all my
machines are quite quick and the code will naturally break the loop with
EOF before the next qualifying ARP packet hits the interface. The only
reason why I just found this now is that my Solaris dev box is emulated
on a NetBSD XEN host and that is quite slow. It takes minutes to boot
rather than seconds the other guests take. Also, the BPF implementation
on Solaris is documented to be quite slow as well .. well slow at
notifying userland of new packets so they queue and expose this error.

I've pushed patches to trunk and dhcpcd-6 branches to fix this.

Roy