incorrect crc32 comparisons

Bug #1119988 reported by Seth Arnold
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
vde2 (Ubuntu)
New
Undecided
Unassigned

Bug Description

cryptcab decided to treat crc32 values as a string for some reason. In doing so, it incorrectly compares two crc32 values:

int
isvalid_crc32(unsigned char *block, int len)
{
        unsigned char *crc=(unsigned char *)crc32(block,len-4);
        if(strncmp((char*)block+(len-4),(char*)crc,4)==0){
                free(crc);
                return 1;
        }else{

                //fprintf(stderr,"bad crc32!\n");
                free(crc);
                return 0;
        }
}

strcmp will stop reading at the first 0x00 character ('\0') in the string, whether it is intentional or not. Further characters are not compared.

If the string implementation is desirable, then this code should switch to memcmp(3), and a specified length of '4'.

However, this entire string-based comparison could probably be replaced if the crc32() were redesigned to use htonl(3) to manipulate the crc32 values as a single four-byte entity. These can be compared using == directly and without invoking malloc(3) and free(3). However, I have not tested that htonl(3) is an accurate replacement, so please be sure to test this thoroughly. (The existing code may actually be incorrect on PowerPC, SPARC, MIPS, etc. I also haven't tested this guess.)

Revision history for this message
Seth Arnold (seth-arnold) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.