vc->hdr_num and len are both 32 bits wide and their product will be a
32-bit result. So any overflow will be lost. Cast hdr_num to unsigned
long long so that nothing is lost if the product overflows a 32-bit
integer.
This fixes the following issue reported by Coverity.
** CID 486274: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
/verify.c: 347 in log_verify_failure()
________________________________________________________________________________________________________
*** CID 486274: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
/verify.c: 347 in log_verify_failure()
341 uint32_t len;
342 struct thread_data *td = vc->td;
343
344 offset = vc->io_u->verify_offset;
345 if (td->o.verify != VERIFY_PATTERN_NO_HDR) {
346 len = hdr->len;
>>> CID 486274: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
>>> Potentially overflowing expression "vc->hdr_num * len" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "unsigned long long" (64 bits, unsigned).
347 offset += vc->hdr_num * len;
348 } else {
349 len = vc->io_u->buflen;
350 }
351
352 log_err("%.8s: verify failed at file %s offset %llu, length %u"
Fixes:
9c8b90ae ("fix wrong offset for VERIFY_PATTERN_NO_HDR")
Signed-off-by: Vincent Fu <vincent.fu@samsung.com>