| commit | 70fa99f445a6fabe4b46f188cc665cd469cd8293 | |
| author | Eric Blake <eblake@redhat.com> | |
| Thu, 8 Jun 2023 13:56:36 +0000 (8 08:56 -0500) | ||
| committer | Eric Blake <eblake@redhat.com> | |
| Wed, 19 Jul 2023 20:26:13 +0000 (19 15:26 -0500) | ||
| tree | 7a258a28ea076d84ad7092edef18f9756d9c2002 | treesnapshot (tar.gz zip) |
| parent | 8cb98a725e7397c9de25ebd77c00b1d5f2d8351e | commitdiff |
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: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20230608135653.2918540-8-eblake@redhat.com>
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: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20230608135653.2918540-8-eblake@redhat.com>
| nbd/client.c | diffblobblamehistory |