From bbb53fb9f72084b5b8f3204356b2b293ac6dc82a Mon Sep 17 00:00:00 2001 From: Koda Reef Date: Mon, 23 Mar 2026 14:23:07 +0000 Subject: [PATCH] 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. --- src/openvpn/crypto_epoch.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/openvpn/crypto_epoch.c b/src/openvpn/crypto_epoch.c index 54225bf0..2f37ba1a 100644 --- a/src/openvpn/crypto_epoch.c +++ b/src/openvpn/crypto_epoch.c @@ -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 */