https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4826
--- Comment #2 from Guy Harris <guy@xxxxxxxxxxxx> 2010-06-02 12:38:06 PDT ---
So the problem appears to be that the SIGCOMP_INSTR_INPUT_BYTES case, in the
if (input_address > ( msg_end - 1)){
current_address = at_address;
result_code = 14;
goto execute_next_instruction;
}
code, was going to execute_next_instruction without bumping the cycle count.
Presumably either RFC 3320 had an error, or we're not correctly implementing
it.
The relevant bits are
8.6. UDVM Cycles
Once the UDVM has been invoked it executes the instructions contained
in its memory consecutively unless otherwise indicated (for example
when the UDVM encounters a JUMP instruction). If the next
instruction to be executed lies outside the available memory then
decompression failure occurs (see Section 8.7).
To ensure that a SigComp message cannot consume excessive processing
resources, SigComp limits the number of "UDVM cycles" allocated to
each message. The number of available UDVM cycles is initialized to
1000 plus the number of bits in the SigComp header (as described in
Section 7); this sum is then multiplied by cycles_per_bit. Each time
an instruction is executed the number of available UDVM cycles is
decreased by the amount specified in Chapter 9. Additionally, if the
UDVM successfully requests n bits of compressed data using one of the
INPUT instructions then the number of available UDVM cycles is
increased by n * cycles_per_bit once the instruction has been
executed.
This means that the maximum number of UDVM cycles available for
processing an n-byte SigComp message is given by the formula:
maximum_UDVM_cycles = (8 * n + 1000) * cycles_per_bit
The reason that this total is not allocated to the UDVM when it is
invoked is that the UDVM can begin to decompress a message that has
only been partially received. So the total message size may not be
known when the UDVM is initialized.
Note that the number of UDVM cycles MUST NOT be increased if a
request for additional compressed data fails.
The UDVM stops executing instructions when it encounters an END-
MESSAGE instruction or if decompression failure occurs (see Section
8.7 for further details).
...
9. UDVM Instruction Set
The UDVM currently understands 36 instructions, chosen to support the
widest possible range of compression algorithms with the minimum
possible overhead.
Figure 11 lists the different instructions and the bytecode values
used to encode the instructions. The cost of each instruction in
UDVM cycles is also given:
Instruction: Bytecode value: Cost in UDVM cycles:
DECOMPRESSION-FAILURE 0 1
AND 1 1
OR 2 1
NOT 3 1
LSHIFT 4 1
RSHIFT 5 1
ADD 6 1
SUBTRACT 7 1
MULTIPLY 8 1
DIVIDE 9 1
REMAINDER 10 1
SORT-ASCENDING 11 1 + k * (ceiling(log2(k)) + n)
SORT-DESCENDING 12 1 + k * (ceiling(log2(k)) + n)
SHA-1 13 1 + length
LOAD 14 1
MULTILOAD 15 1 + n
PUSH 16 1
POP 17 1
COPY 18 1 + length
COPY-LITERAL 19 1 + length
COPY-OFFSET 20 1 + length
MEMSET 21 1 + length
JUMP 22 1
COMPARE 23 1
CALL 24 1
RETURN 25 1
SWITCH 26 1 + n
CRC 27 1 + length
INPUT-BYTES 28 1 + length
INPUT-BITS 29 1
INPUT-HUFFMAN 30 1 + n
STATE-ACCESS 31 1 + state_length
STATE-CREATE 32 1 + state_length
STATE-FREE 33 1
OUTPUT 34 1 + output_length
END-MESSAGE 35 1 + state_length
Figure 11: UDVM instructions and corresponding bytecode values
Each UDVM instruction costs a minimum of 1 UDVM cycle. Certain
instructions may cost additional cycles depending on the values of
the instruction operands. Named variables in the cost expressions
refer to the values of the instruction operands with these names.
Note that for the SORT instructions, the formula ceiling(log2(k))
calculates the smallest value i such that k <= 2^i.
Is that particular case (input_address > ( msg_end - 1)) a failure case? If
so, it should be terminating the execution of the program, and we should check
for other failure cases that aren't failing.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
