CSTP reconnect segfault on HEAD

[Jack Miller]

All -

First of all, I've used openconnect for quite awhile and it's been nothing
but solid, so thanks.

Recently, I noticed that it's been segfaulting about every hour, so I built
from git and fired it up in GDB. I got this backtrace:

---------------------8<---------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
queue_packet (q=<optimized out>, q at entry=0x62fd78, new=0x0) at mainloop.c:40
40              new->next = NULL;
(gdb) bt
#0  queue_packet (q=<optimized out>, q at entry=0x62fd78, new=0x0)
    at mainloop.c:40
#1  0x00000000004081fb in cstp_reconnect (vpninfo=vpninfo at entry=0x62f7c0)
    at cstp.c:535
#2  0x0000000000406a98 in dtls_mainloop (vpninfo=vpninfo at entry=0x62f7c0, 
    timeout=timeout at entry=0x7fffffffe07c) at dtls.c:725
#3  0x0000000000409003 in vpn_mainloop (vpninfo=vpninfo at entry=0x62f7c0)
    at mainloop.c:90
#4  0x0000000000403fe2 in main (argc=6, argv=0x7fffffffe6b8) at main.c:852
(gdb) 
--------------------------------------------------------------------------

Obviously, on the surface, new is NULL dereferenced which is no good. I made
a shallow patch that bails out of queue_packet() if !new which appears to
work, but considering this has worked for so long before I imagine that an
assumption higher up has been broken.

I'm invoking with:
--script=/etc/vpnc/vpnc-script --user=[myuser] --syslog --no-deflate [vpn
target]

I've reproduced this on 3.18+ and this trace is from HEAD. I'm running Arch
Linux with kernels 3.3.2 - 3.4.4. I can't vouch for the sanity of or any
changes in company's VPN setup other than the fact that it was working before
and other clients don't seem to object to it. Let me know if I can provide
any more information.

- Jack