On 7/28/26 12:24 AM, Tristan Madani wrote: > 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; > + } Hi, Tristan. Thanks for the patch and sorry for delay.
This change does cover one scenario, but we can still end up overflowing the log_end later if the number of entries we're adding will shift the log past the UINT64_MAX. If we want to have a better coverage here, shouldn't the check be more broad, e.g.: q->n_entries >= UINT64_MAX - rq->prev_log_index ? We may also want a check for the last index in other places like the raft_handle_install_snapshot_request() as we can have an overflow there from a incorrect incoming request. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
