in bluetooth/host/gatt.c, the notify member of bt_gatt_subscribe_params is called without checking for a null pointer. In my central, the peripheral disconnected while I was subscribed to an attribute and unbeknownst to me, the subscription was still maintained. Upon disconnect, I zeroed the params and wiped out the notify pointer which was eventually called. Adding BT_GATT_SUBSCRIBE_FLAG_VOLATILE resolved the problem. Additionally, the behavior only happens with a LESC bonded connection. Possible ways that I see to fix this:
* check for null pointer before calling notify() and either skip it or perhaps panic
* set the volatile flag by default (I don't know BLE well, so maybe this is part of the standard as it is)
* adjust the logic in gatt.c:remove_subscriptions() to perform the same regardless of the bonding state

Mike