mirror of
https://github.com/OpenVPN/openvpn.git
synced 2026-05-28 04:03:29 -04:00
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:
parent
000f9d97a1
commit
bbb53fb9f7
1 changed files with 6 additions and 0 deletions
|
|
@ -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 */
|
||||
|
|
|
|||
Loading…
Reference in a new issue