Subject: | GSS krb5 sequence number checking fails on initial gap token |
Text from a pull request by Tomas Kuthan <tkuthan@gmail.com>:
-----
g_order_check() fails iff first token arrives out-of-order
After the queue was re-written to store deltas from firstnum, the first
(dummy) element was changed from firstnum-1 to (-1 & mask). Now, when
the firstnum arrives out of order, it should be inserted between the
dummy element and the element that arrived first. But its delta from
firstnum is zero, which is not greater that the value of dummy element
(all ones binary). It doesn't fit in any other place in the queue
either, and g_order_check returns GSS_S_FAILURE, which (according to the
comment) should never happen.
To reproduce: 2 - 1 - 3
Expected outcome: GSS_S_GAP_TOKEN, GSS_S_UNSEQ_TOKEN, GSS_S_COMPLETE
Actual outcome: GSS_S_GAP_TOKEN, GSS_S_FAILURE, GSS_S_COMPLETE
-----
Ticket #2040 is where util_order.c was changed to store relative
sequence numbers in the queue, introducing this bug.
-----
g_order_check() fails iff first token arrives out-of-order
After the queue was re-written to store deltas from firstnum, the first
(dummy) element was changed from firstnum-1 to (-1 & mask). Now, when
the firstnum arrives out of order, it should be inserted between the
dummy element and the element that arrived first. But its delta from
firstnum is zero, which is not greater that the value of dummy element
(all ones binary). It doesn't fit in any other place in the queue
either, and g_order_check returns GSS_S_FAILURE, which (according to the
comment) should never happen.
To reproduce: 2 - 1 - 3
Expected outcome: GSS_S_GAP_TOKEN, GSS_S_UNSEQ_TOKEN, GSS_S_COMPLETE
Actual outcome: GSS_S_GAP_TOKEN, GSS_S_FAILURE, GSS_S_COMPLETE
-----
Ticket #2040 is where util_order.c was changed to store relative
sequence numbers in the queue, introducing this bug.