Skip to content
Snippets Groups Projects
Commit 70fa99f4 authored by Eric Blake's avatar Eric Blake
Browse files

nbd/client: Add safety check on chunk payload length


Our existing use of structured replies either reads into a qiov capped
at 32M (NBD_CMD_READ) or caps allocation to 1000 bytes (see
NBD_MAX_MALLOC_PAYLOAD in block/nbd.c).  But the existing length
checks are rather late; if we encounter a buggy (or malicious) server
that sends a super-large payload length, we should drop the connection
right then rather than assuming the layer on top will be careful.
This becomes more important when we permit 64-bit lengths which are
even more likely to have the potential for attempted denial of service
abuse.

Signed-off-by: default avatarEric Blake <eblake@redhat.com>
Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20230608135653.2918540-8-eblake@redhat.com>
parent 8cb98a72
No related branches found
No related tags found
No related merge requests found
......@@ -1413,6 +1413,18 @@ static int nbd_receive_structured_reply_chunk(QIOChannel *ioc,
chunk->cookie = be64_to_cpu(chunk->cookie);
chunk->length = be32_to_cpu(chunk->length);
/*
* Because we use BLOCK_STATUS with REQ_ONE, and cap READ requests
* at 32M, no valid server should send us payload larger than
* this. Even if we stopped using REQ_ONE, sane servers will cap
* the number of extents they return for block status.
*/
if (chunk->length > NBD_MAX_BUFFER_SIZE + sizeof(NBDStructuredReadData)) {
error_setg(errp, "server chunk %" PRIu32 " (%s) payload is too long",
chunk->type, nbd_rep_lookup(chunk->type));
return -EINVAL;
}
return 0;
}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment