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