4845b77245
When processing the arguments list for a v2 ls-refs or fetch command, we
loop like this:
while (packet_reader_read(request) != PACKET_READ_FLUSH) {
const char *arg = request->line;
...handle arg...
}
to read and handle packets until we see a flush. The hidden assumption
here is that anything except PACKET_READ_FLUSH will give us valid packet
data to read. But that's not true; PACKET_READ_DELIM or PACKET_READ_EOF
will leave packet->line as NULL, and we'll segfault trying to look at
it.
Instead, we should follow the more careful model demonstrated on the
client side (e.g., in process_capabilities_v2): keep looping as long
as we get normal packets, and then make sure that we broke out of the
loop due to a real flush. That fixes the segfault and correctly
diagnoses any unexpected input from the client.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
34 lines
965 B
Bash
Executable File
34 lines
965 B
Bash
Executable File
#!/bin/sh
|
|
|
|
test_description='Test responses to violations of the network protocol. In most
|
|
of these cases it will generally be acceptable for one side to break off
|
|
communications if the other side says something unexpected. We are mostly
|
|
making sure that we do not segfault or otherwise behave badly.'
|
|
. ./test-lib.sh
|
|
|
|
test_expect_success 'extra delim packet in v2 ls-refs args' '
|
|
{
|
|
packetize command=ls-refs &&
|
|
printf 0001 &&
|
|
# protocol expects 0000 flush here
|
|
printf 0001
|
|
} >input &&
|
|
test_must_fail env GIT_PROTOCOL=version=2 \
|
|
git upload-pack . <input 2>err &&
|
|
test_i18ngrep "expected flush after ls-refs arguments" err
|
|
'
|
|
|
|
test_expect_success 'extra delim packet in v2 fetch args' '
|
|
{
|
|
packetize command=fetch &&
|
|
printf 0001 &&
|
|
# protocol expects 0000 flush here
|
|
printf 0001
|
|
} >input &&
|
|
test_must_fail env GIT_PROTOCOL=version=2 \
|
|
git upload-pack . <input 2>err &&
|
|
test_i18ngrep "expected flush after fetch arguments" err
|
|
'
|
|
|
|
test_done
|