g_malloc() will only return NULL iff zero bytes are requested. This may be the case here (although it's *extremely* unlikely), but if so, the returned memory is not touched either.

If l1 is NULL, l1_sz2 will be 0 as well and so will be l1_sz (as long as there are no overflows; to fix this, we'd have to cast l1_sz to uint64_t before multiplying, but this would be a different problem).

bdrv_pread() is then asked to read 0 bytes into a NULL buffer, which will do exactly nothing, so no problem here.

The index access in the following "for" loop (which is signaled by covscan) will not take place, as the loop is taken l1_sz times (which is 0).

Therefore, if g_malloc() returns NULL, the pointer will not be dereferenced. Because I cannot think of any way to tell covscan that this is indeed not a bug, I'll close this BZ.

The only problem might be the multiplication which can theoretically overflow. In practice, this is not an issue on systems with a 64 bit size_t and furthermore this code path is inactive by default, so I don't see a need to fix this, either. Feel free to reopen this BZ if you do, though.

After talking to Paolo upstream, it seems that both this and 1102409 should be fixed by backporting (or using) the coverity model upstream provides.

That model assures coverity that g_realloc() and the like never return NULL; this is not true because it will return NULL if 0 bytes are requested. However, in this case (as stated above), the pointer will not be dereferenced anyway; therefore it is easier to just assure coverity that the pointer returned is always valid. Suppressing false positives such as this and 1102409 apparently outweighs some false negatives.

*** This bug has been marked as a duplicate of bug 1102409 ***