From: Tristan Madani <[email protected]>
raft_handle_install_snapshot_request__() computes new_log_start as
rq->last_index + 1. When last_index is UINT64_MAX, new_log_start
wraps to 0, which bypasses the Case 1 and Case 2 early returns
(both compare new_log_start against log_start/log_end and expect
it to be a valid log index). The function then falls through to
Case 3, setting log_start = log_end = 0 and log_synced to
UINT64_MAX (via log_end - 1), corrupting all subsequent log
index arithmetic.
No valid Raft snapshot can have a last_index of UINT64_MAX, so reject
such requests early.
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered
databases.")
Signed-off-by: Tristan Madani <[email protected]>
---
ovsdb/raft.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/ovsdb/raft.c b/ovsdb/raft.c
index e50f1f7..23fe3ac 100644
--- a/ovsdb/raft.c
+++ b/ovsdb/raft.c
@@ -4417,6 +4417,11 @@ raft_handle_install_snapshot_request__(
{
raft_reset_election_timer(raft);
+ /* Reject last_index that would overflow new_log_start computation. */
+ if (rq->last_index == UINT64_MAX) {
+ return false;
+ }
+
/*
* Our behavior here depend on new_log_start in the snapshot compared to
* log_start and log_end. There are three cases:
--
2.53.0
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
