In isakmpd's pf_key_v2_enable_sa(), check if proto is NULL and if so,
authorsthen <sthen@openbsd.org>
Mon, 31 Jan 2022 23:51:15 +0000 (23:51 +0000)
committersthen <sthen@openbsd.org>
Mon, 31 Jan 2022 23:51:15 +0000 (23:51 +0000)
commitb255ec9040c5acadf982f73eafa7d1fddfe19ae8
treef2c3f7af3db17dbea38ce6fd80f82541505fb2ac
parent60bba061ba9bc8584d3036ae219cbc84423a7e01
In isakmpd's pf_key_v2_enable_sa(), check if proto is NULL and if so,
log a warning rather than attempting to dereference it. Check suggested by
millert@, ok "your fix shouldn't hurt" mpi@

This isn't fixing the root cause but I don't have a better idea and I'm
hitting problems on several systems as I upgrade them, and I think in this
case logging rather than dumping core is more helpful.

Without this, in recent OpenBSD versions (I have seen it in since at least
the snapshot from June 14 2021) I am often seeing isakmpd crashes after
SAs come in shortly after isakmpd starts with my usual flags, although
they don't seem to occur if I raise logs to heavy debug levels (-DA=90).

With this, those connections will fail but isakmpd will stay running and
after usually one retry things will be ok.

Usually, perhaps always, seen associated with "responder_recv_HASH_SA_NONCE:
KEY_EXCH payload without a group desc. attribute" logged previously.
Pcap written by isakmpd -L shows a normal-looking proposal though, with
proto/ids/group description set, yet printing *isa at the point that message
is logged shows zeros in sport/dport/group_desc/etc.

(I can give more info and/or test if someone has a better idea!)
sbin/isakmpd/pf_key_v2.c