[SERVER-15112] 14 of last 15 bytes of journal section may be ignored in computing hash Created: 02/Sep/14  Updated: 06/Dec/22  Resolved: 14/Sep/18

Status: Closed
Project: Core Server
Component/s: MMAPv1, Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Bruce Lucas (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-20266 Use ConstDataCursor to read buffer in... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

In Checksum::gen in util/checksum.h:

  • there are up to 15 bytes left over after computing "a" and "b", but they are packed into the 8-byte word "c", so up to 7 may get lost.
  • the bytes are extracted as char, not unsigned char, so they get sign extended then or'ed, so the previously packed bytes may get obscured by the sign bit of the new byte. This code may also be non-portable as it depends on the signedness of the char type.

The net result is that up to 14 of the last 15 bytes may get ignored in the hash. This seems highly unlikely to make a difference in practice however.



 Comments   
Comment by Tess Avitabile (Inactive) [ 08/Jun/16 ]

That is correct.

Comment by Asya Kamsky [ 06/Jun/16 ]

With SERVER-20266 fixed, what's the impact on this ticket?

Comment by Bruce Lucas (Inactive) [ 02/Sep/14 ]

c is used indeed, but

  • it holds only 8 bytes, whereas up to 15 are left over after a and b are computed (the comment "0-7 bytes left" is incorrect) since n = floor(len/16) and i ranges from n*16 to len. This loses up to 7 bytes from the hash.
  • the chars are sign-extended before they are or'ed into to the low-order 8 bits of c, potentially replacing the chars that have already been packed into c with 0xFF. The last byte packed in is the only one guaranteed not to be replaced with 0xFF, so up to 7 bytes of c are effectively ignored.
Comment by Dwight Merriman [ 02/Sep/14 ]

words[0] = a ^ len;
words[1] = b ^ c;

it looks to me that what was in c gets used am i misreading?

Generated at Thu Feb 08 03:36:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.