CRC32 verification depends on an unprotected bit that could be corrupted

[moonlight83340]

Brief When using LIBCSP with the CSP_O_CRC32 option, we should throw away corrupted messages. However, if the option bit is corrupted, I think the packet can bypass the security route because it wouldn't be verified.

Current understanding I found in the source code how the packet can skip the security path with a bit change in the packet header: https://github.com/libcsp/libcsp/blob/develop/src/csp_route.c#L63

Expected behavior If a message is corrupted, it should be thrown away.

Impact A message can pass the CRC32 security with only a bit change, which shouldn't be the case.

Correction I don't know yet how to avoid this situation, but I wanted to share it with others.