From: Tristan Madani <[email protected]>
raft_handle_append_request() computes first_entry_index as
prev_log_index + 1. When prev_log_index is UINT64_MAX, this 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.
Additionally, the n_entries - ofs subtraction underflows, producing
a very large iteration count in raft_handle_append_entries().
No valid Raft log index can be UINT64_MAX, so reject the message
early with RAFT_APPEND_INCONSISTENCY.
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered
databases.")
Signed-off-by: Tristan Madani <[email protected]>
---
ovsdb/raft.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/ovsdb/raft.c b/ovsdb/raft.c
index b1355d41..d1816d47 100644
--- a/ovsdb/raft.c
+++ b/ovsdb/raft.c
@@ -3458,6 +3458,14 @@ raft_handle_append_request(struct raft *raft,
}
raft_reset_election_timer(raft);
+ /* Reject prev_log_index values that would cause first_entry_index
+ * (prev_log_index + 1) to wrap around to 0. */
+ if (rq->prev_log_index == UINT64_MAX) {
+ raft_send_append_reply(raft, rq, RAFT_APPEND_INCONSISTENCY,
+ "prev_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
