calloc(nelem, size) is supposed to allocate sufficient heap memory to hold "nelem" copies of "size" bytes, for a total of nelem*size bytes, and return a pointer to this memory, or NULL if the request cannot be satisfied. The bug here is that certain input values that represent an allocation request that is too large to fulfill could cause calloc to return a non-NULL pointer anyway because the unsigned multiplication to compute the total size needed wraps around to a smaller value that could be allocated, but wouldn't be big enough for the user's request. A calling function would assume this too-small packet had the full size requested, and would likely write beyond the end of the packet, causing memory corruption.

For example, on a 32-bit target, if the user calls calloc(0x00010001, 0x00010001), even though each argument by itself is reasonable, the request cannot be satisfied because the product is 0x000100020001, which exceeds size_t, and would wrap around to the value 0x20001. The heap might be able to handle a request of that size and would allocate some space and return a non-NULL pointer, but the allocated space wouldn't be nearly large enough for the user's request. The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough to overflow size_t. It may not be obvious to the user that this overflows.