The function in question only used by the dataset send/receive functionality to compute the checksum of the resume token, and by the zdb debug tool which is used to inspect the filesystem.
Importantly, it's not the function used to compute the checksum of the blocks on disk.
The resume token contains a header which includes the checksum in question as well as the length of the decompressed data in the token, followed by compressed data. The code checks that the length of the decompressed data matches the value stored in the header.
So, this means that the possibility for corruption is only when receiving a dataset and the token is corrupted in a way where Zlib decompresses the correct amount of data, but the last few bytes are incorrect.
The function in question only used by the dataset send/receive functionality to compute the checksum of the resume token, and by the zdb debug tool which is used to inspect the filesystem.
Importantly, it's not the function used to compute the checksum of the blocks on disk.
The resume token contains a header which includes the checksum in question as well as the length of the decompressed data in the token, followed by compressed data. The code checks that the length of the decompressed data matches the value stored in the header.
So, this means that the possibility for corruption is only when receiving a dataset and the token is corrupted in a way where Zlib decompresses the correct amount of data, but the last few bytes are incorrect.