On 10/26/2015 04:06 PM, John Snow wrote: > Make sure there's not trailing garbage, e.g. > "64k-whatever-i-want-here" > > Reported-by: Max Reitz <[email protected]> > Signed-off-by: John Snow <[email protected]> > --- > qemu-io-cmds.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) >
> diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
> index 07c5681..e2477fc 100644
> --- a/qemu-io-cmds.c
> +++ b/qemu-io-cmds.c
> @@ -136,7 +136,14 @@ static char **breakline(char *input, int *count)
> static int64_t cvtnum(const char *s)
> {
> char *end;
> - return qemu_strtosz_suffix(s, &end, QEMU_STRTOSZ_DEFSUFFIX_B);
> + int64_t ret;
> +
> + ret = qemu_strtosz_suffix(s, &end, QEMU_STRTOSZ_DEFSUFFIX_B);
> + if (*end != '\0') {
> + /* Detritus at the end of the string */
> + return -EINVAL;
> + }
> + return ret;
> }
Eww. This mixes up two return types, negative errno, and negative
input. User input of -22 shouldn't behave differently than -21, just
because it happens to match -EINVAL.
Do we ever want to allow a negative return from cvtnum(), or should we
just blindly map a negative int64_t into -ERANGE for a contract that we
only accept 63-bit numbers?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
