Closed Drawishe closed 4 months ago
@michaelrsweet I'm not sure here, can you look into it?
In the future, please don't mix separate issues in a single bug.
Issue 1 (ipp.c): FALSE POSITIVE
This is not a valid security or crash concern. The code in question uses UNSIGNED characters with values from 0 to 255. Left shifting might result in bit 7 of the first byte resulting in a signed 32-bit integer result, but THAT IS INTENTIONAL since IPP integers are two's complement (signed) values.
Issue 2 (string.c): FALSE POSITIVE
The string pool makes use of one or two 32-bit integers at the beginning of the string (one is an optional guard and the other a reference counter). _cupsStrAlloc
passes an offset string pointer to cupsArrayFind
in order to determine whether the string is already in the pool. From the standpoint of the tools, this results in an "unaligned" pointer (more a pointer that is aligned to 32 bits instead of 64) but since we are comparing character strings the alignment requirement does not exist (char accesses are necessarily not aligned since you might need to access the Nth character of a string and not break things...)
Building a project with the gcc compiler with the
-fsanitize=undefined
option and running oss-fuzz targets on collected corpus resulted in some crashes.Several crashes were found in the
ipp.c
file. Here they are:All of them arise from potential integer overflow due to bitwise operations - the result of shifting left char variable is assigned to int variable, which in some cases can cause integer overflow (if char variable, shifting left by 24 bits, has value >= 128).
Is this normal behaviour in cups, or is there some undefined behaviour? Do we need to cast it to an unsigned integer or some other type of variable?
Also, ubsan found some crashes in
string.c
file, which are associated with address missalignment:System information: