I don’t think so - testing it in the netconf_notifications example, it seems it just returns CONFD_EOF, as could be expected. Perhaps your application code doesn’t handle that return value correctly, causing the crash?
There is a “minor” issue due to the semantics of TCP connections, though - at least for “small” notifications, the first call of confd_notification_send() after the connection has been lost will actually succeed, and only the second call will result in CONFD_EOF (still no crash).
This issue can be avoided by doing what the example code does, i.e. include the daemon control socket in the poll() set. That way you get an immediate notification already when the connection is lost, and can take appropriate action. (I had to comment-out the handling of control-socket-ready-for-reading in order to do the test above.)