With SDK15.3 (it appears the issue exists in 17.1 as well), we are using the flash backend. To read the logs, we are doing the equivalent of flashlog_read_cmd(). This eventually calls nrf_log_color_id_get() and nrf_log_module_name_get(). I see that nrf_log_module_name_get() essentially validates module_id through the module_idx_get() call, but nrf_log_color_id_get() directly calls NRF_LOG_CONST_SECTION_VARS_GET(module_id). There is no validation on module_id, meaning if module_id is excessively high, a hardfault may occur in the NRF_LOG_CONST_SECTION_VARS_GET().
Ideally, module_id shouldn't be corrupted, but when using the flash backend, module_id is read from flash. There is the possibility that it could be invalid. I'd recommend adding some defensive programming around module_id such that even if the flash sector has corruption, at a minimum a hardfault won't occur.
In our specific scenario, we sometimes use the flash backend sectors for other purposes and flash wasn't always fully erased when reenabling the sector for logging. We'll fix this issue, but it seems like corruption could happen for other reasons such as power loss during writes/erases.
