From: Tristan Madani <[email protected]>
raft_handle_append_request() computes first_entry_index as
prev_log_index + 1 and nth_entry_index as prev_log_index + n_entries.
When prev_log_index is UINT64_MAX, first_entry_index wraps to 0, which
combined with an empty entries array (n_entries=0, so xmalloc(0) returns
a 1-byte allocation) causes the slow-path fallthrough at the end of the
function to read entries[ofs - 1] well past the allocated buffer.
More generally, if prev_log_index + n_entries overflows UINT64_MAX, the
computed nth_entry_index wraps around, causing incorrect comparisons
against log_start throughout the function and potentially corrupting log
state via raft_handle_append_entries().
Reject the message early when prev_log_index + 1 or
prev_log_index + n_entries would overflow.
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered
databases.")
Signed-off-by: Tristan Madani <[email protected]>
---
ovsdb/raft.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/ovsdb/raft.c b/ovsdb/raft.c
index 2bdd317..e50f1f7 100644
--- a/ovsdb/raft.c
+++ b/ovsdb/raft.c
@@ -3459,6 +3459,15 @@ raft_handle_append_request(struct raft *raft,
}
raft_reset_election_timer(raft);
+ /* Reject requests where prev_log_index + 1 or prev_log_index + n_entries
+ * would overflow, which would corrupt index arithmetic below. */
+ if (rq->prev_log_index == UINT64_MAX
+ || rq->n_entries > UINT64_MAX - rq->prev_log_index) {
+ raft_send_append_reply(raft, rq, RAFT_APPEND_INCONSISTENCY,
+ "log index overflow");
+ return;
+ }
+
/* First check for the common case, where the AppendEntries request is
* entirely for indexes covered by 'log_start' ... 'log_end - 1', something
* like this:
--
2.53.0
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
