On 11/09/2017 03:37 AM, Vladimir Sementsov-Ogievskiy wrote: > 09.11.2017 00:57, Eric Blake wrote: >> Ensure that the server is not sending unexpected chunk lengths >> for either the NONE or the OFFSET_DATA chunk, nor unexpected >> hole length for OFFSET_HOLE. This will flag any server that >> responds to a zero-length read with an OFFSET_DATA as broken, > > or OFFSET_HOLE
True, even though our implementation was not doing that. I can tweak
the commit message.
>
>> even though we previously fixed our client to never be able to
>> send such a request over the wire.
>>
>> Signed-off-by: Eric Blake <ebl...@redhat.com>
>> ---
>> block/nbd-client.c | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> @@ -281,7 +281,8 @@ static int
>> nbd_co_receive_offset_data_payload(NBDClientSession *s,
>>
>> assert(nbd_reply_is_structured(&s->reply));
>>
>> - if (chunk->length < sizeof(offset)) {
>> + /* The NBD spec requires at least one byte of payload */
>> + if (chunk->length <= sizeof(offset)) {
>> error_setg(errp, "Protocol error: invalid payload for "
>> "NBD_REPLY_TYPE_OFFSET_DATA");
>> return -EINVAL;
>> @@ -293,7 +294,7 @@ static int
>> nbd_co_receive_offset_data_payload(NBDClientSession *s,
>> be64_to_cpus(&offset);
>>
>> data_size = chunk->length - sizeof(offset);
>> - if (offset < orig_offset || data_size > qiov->size ||
>> + if (!data_size || offset < orig_offset || data_size > qiov->size ||
>
> !data_size - always false here (because of previous check), and even if
> it could be zero it
> isn't correspond to error message.
>
> without this, or with an assert instead:
I like the assert instead.
>
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
>
>
Thanks for the reviews; I'll queue this series onto my NBD tree with
your suggestions incorporated, and send a pull request for 2.11 shortly.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
