From: Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Cyrill Gorcunov <gorcunov@gmail.com>, tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] raft: more precise verification of incoming request state Date: Fri, 25 Jun 2021 23:49:10 +0200 [thread overview] Message-ID: <9652278e-570e-40e5-b2d1-856fe58179fc@tarantool.org> (raw) In-Reply-To: <20210625100707.87807-1-gorcunov@gmail.com> Hi! Thanks for the patch! On 25.06.2021 12:07, Cyrill Gorcunov via Tarantool-patches wrote: > When new raft message comes in from the network we need > to be sure that the payload is suitable for processing, > in particular `raft_msg::state` must be valid because > our code logic depends on it. > > Since the `raft_msg::state` is declared as enum the > its processing is implementation defined an a compiler > might treat it as unsigned or signed int. In the latter > case the `if` statement won't be taken which will lead > to undefined behaviour. So > > 1) Use explicit unsigned type conversion to make sure > the `state` requested is valid; > 2) Use panic() instead of unreacheable() macro; > 3) Extend testing. > > Closes #6067 Unfortunately, the patch does not fix much. Firstly, the state is decoded from MessagePack as mp_decode_uint(). It can't be negative originally by design. Secondly, and most importantly, the state is decoded as uint64_t raft_request.state, but it is saved without checks into enum struct raft_msg.state in box_raft_request_to_msg(). So the current patch does not change almost anything I suppose? Because if I send ((UINT32_MAX << 31) | 0x01), it will work. Because the upper 32 bits would be truncated (assuming the enum is 32 bits), and your checks are done too late to notice it. Correct? If so, then I would propose to fix the issue entirely, if you want to work on that. > diff --git a/src/lib/raft/raft.c b/src/lib/raft/raft.c > index eacdddb7e..409e983f0 100644 > --- a/src/lib/raft/raft.c > +++ b/src/lib/raft/raft.c > @@ -309,7 +309,9 @@ raft_process_msg(struct raft *raft, const struct raft_msg *req, uint32_t source) > say_info("RAFT: message %s from %u", raft_msg_to_string(req), source); > assert(source > 0); > assert(source != raft->self); > - if (req->term == 0 || req->state == 0 || req->state >= raft_state_MAX) { > + > + if (req->term == 0 || req->state == 0 || > + (unsigned)req->state >= raft_state_MAX) { Please, perform a normal < 0 comparison. No need for unsigned cast cast.
next prev parent reply other threads:[~2021-06-25 21:49 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-25 10:07 Cyrill Gorcunov via Tarantool-patches 2021-06-25 21:49 ` Vladislav Shpilevoy via Tarantool-patches [this message] 2021-06-25 21:49 ` Vladislav Shpilevoy via Tarantool-patches 2021-06-26 13:34 ` Cyrill Gorcunov via Tarantool-patches 2021-06-27 14:12 ` Vladislav Shpilevoy via Tarantool-patches 2021-06-27 19:42 ` Cyrill Gorcunov via Tarantool-patches 2021-07-02 13:43 ` Cyrill Gorcunov via Tarantool-patches 2021-07-07 21:25 ` Vladislav Shpilevoy via Tarantool-patches 2021-07-07 21:59 ` Cyrill Gorcunov via Tarantool-patches 2021-07-07 22:05 ` Cyrill Gorcunov via Tarantool-patches 2021-07-08 9:28 ` [Tarantool-patches] [PATCH v3] raft: change request state to uint64_t Cyrill Gorcunov via Tarantool-patches 2021-07-08 21:17 ` Vladislav Shpilevoy via Tarantool-patches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=9652278e-570e-40e5-b2d1-856fe58179fc@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=gorcunov@gmail.com \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH] raft: more precise verification of incoming request state' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox