Revisiting coap_session_release() when deleting observers

[obgm]

The functions coap_delete_observer() and coap_delete_observers() call coap_session_release() which might free the passed session object. This will lead to invalid reads at several occasions:

coap_session_disconnected(): Here, the session object is used after coap_delete_observers() was called. Moving to the end most likely does not work due to caller context of coap_session_disconnected(). (CID 1484385 reported by Coverity scan.)

coap_add_observer() calls coap_delete_observer() when an existing observation relationship is to be replaced. (CID 1484383 reported by Coverity scan.)

In coap_read_endpoint() which may eventually call coap_session_disconnected() (and thus coap_delete_observers()). (CID 1484382 reported by Coverity scan.)

In coap_dispatch() which calls coap_cancel(). (CID 1484381 reported by Coverity scan.)

Also seen in CID 1484379 (due to coap_session_disconnected()).

[mrdeep1]

Hmm. Given that observers are only associated with servers, and coap_session_release() only calls coap_session_free() if the session is a client I am not sure that there actually is an issue here.

[mrdeep1]

Actually, if Call-Home is implemented (aka RFC8071), where (D)TLS is set up in the opposite direction to CoAP, then it is possible that the Observer Subscription is in the (D)TLS client which is the CoAP server. [The CoAP role reversal is easily set up when event COAP_EVENT_DTLS_CONNECTED is triggered.]

So, further research is needed here to check out whether there are any actual issues here. It may be that the session object has to be put on a final delete queue which is purged when, say, returning from coap_read().