[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry
>>> On 19.08.16 at 10:06, <wei.liu2@xxxxxxxxxx> wrote: > Coverity complains: > > overflow_before_widen: Potentially overflowing expression > info->nr_modules * 32U 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 uint64_t (64 bits, unsigned). To me this is Coverity splitting hair, to be honest. > --- a/tools/firmware/hvmloader/hvmloader.c > +++ b/tools/firmware/hvmloader/hvmloader.c > @@ -272,8 +272,8 @@ const struct hvm_modlist_entry *get_module_entry( > > if ( !modlist || > info->modlist_paddr > UINTPTR_MAX || > - (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1) > - > UINTPTR_MAX ) > + (info->modlist_paddr + > + (uint64_t)info->nr_modules * sizeof(*modlist) - 1) > UINTPTR_MAX ) > return NULL; This can be had without resorting to 64-bit multiplication, by bounds checking (UINTPTR_MAX - (uintptr_t)info->modlist_paddr) / sizeof(*modlist) instead. While we would certainly hope that compilers don't resort to a libgcc helper for 64-bit multiplication, I think we'd better avoid that risk altogether. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |