On 10/7/26 8:56 PM, [email protected] wrote:
> 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.
This explanation doesn't seem correct. It wraps to zero, but
then the Case 1 pretty much always catches that and returns early,
and zero is pretty much always less than the log_start.
Best regards, Ilya Maximets.
>
> 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:
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
