Assume that reject messages for blocks or transactions due to reason REJECT_MALFORMED will not include the hash of the block or tx being rejected.
I found BIP 61 to be slightly ambiguous on how to deserialize in this case, but it seems logical to assume that the peer would have bailed out on parsing the message and thus wouldn't know what hash to include. This is also consistent with the behavior of bitcoin core.
@MarcoFalke Should these strings "block" and "tx" have the b prepended to them as well? I wasn't sure if leaving them out of #7853 was intentional or an oversight.