Re: [Qemu-devel] [PATCH 04/14] qemu-nbd: Simplify --partition handling

[Eric Blake <eblake@redhat.com>]

On 12/5/18 10:26 AM, Eric Blake wrote:

>> is it possible, that "char *ep" remains uninitialized, and than we access
>> it in check_strtox_error? I don's see in strtol spec a guarantee of 
>> setting
>> endptr on failure path.
> 
> C99 7.10.1.4 P5-7 requires strtoll() and friends to assign through 
> 'endptr' if it is non-NULL, for both success and ERANGE failure cases. 
> POSIX then further requires 'endptr' to be set for EINVAL failures due 
> to out-of-range 'base' (not that we have any such callers), and permits 
> (but does not require) the empty string to cause an EINVAL failure (but 
> whether or not EINVAL happened, 'endptr' is still set).  There are no 
> other possible failures, so no, we are not dereferencing an 
> uninitialized variable in check_strtox_error.

Correction, quoting POSIX:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html

APPLICATION USAGE

     Since the value of *endptr is unspecified if the value of base is 
not supported, applications should either ensure that base has a 
supported value (0 or between 2 and 36) before the call, or check for an 
[EINVAL] error before examining *endptr.

So yes, we CAN end up transferring an uninitialized variable into the 
caller's non-NULL endpointer if the caller passes an out-of-range base 
(this particular caller passes NULL for an endpointer, and an in-range 
base, so it's not an issue).  Might be worth a separate patch to assert 
that base is in range for all of the qemu_strto* helpers, if we are 
worried (I'm not).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org