[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 04/14] qemu-nbd: Simplify --partiti

From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 04/14] qemu-nbd: Simplify --partition handling
Date: Wed, 5 Dec 2018 10:32:35 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

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 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:



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]