Clamp epoch key generation count to array bounds

epoch_generate_future_receive_keys() computes num_keys_generate
as the difference between desired and current highest epoch keys.
A large epoch jump from the peer (e.g., from epoch 100 to 65000)
makes num_keys_generate much larger than the epoch_data_keys_future
array size. The ASSERT at line 253 catches this in debug builds
but is compiled out in release, leading to OOB array access.

Clamp num_keys_generate to epoch_data_keys_future_count before
the loop and memmove to prevent out-of-bounds access in all builds.
This commit is contained in:
Koda Reef 2026-03-23 14:23:07 +00:00
parent 000f9d97a1
commit bbb53fb9f7

View file

@ -245,6 +245,12 @@ epoch_generate_future_receive_keys(struct crypto_options *co)
uint16_t desired_highest_key = current_decrypt_epoch + co->epoch_data_keys_future_count;
uint16_t num_keys_generate = desired_highest_key - current_highest_key;
/* Clamp to array bounds to prevent OOB access from large epoch jumps */
if (num_keys_generate > co->epoch_data_keys_future_count)
{
num_keys_generate = co->epoch_data_keys_future_count;
}
/* Move the old keys out of the way so the order of keys stays strictly
* monotonic and consecutive. */
/* first check that the destination we are going to overwrite is freed */