All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Colin King <colin.king@canonical.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH][next] nvmem: core: Fix unintentional sign extension issue
Date: Thu, 11 Mar 2021 09:12:40 -0800	[thread overview]
Message-ID: <CAD=FV=V5+GvMpD1FdX0-TJ=BFyyvST+oLR08pO7jL+h38G8PCw@mail.gmail.com> (raw)
In-Reply-To: <20210311095316.6480-1-colin.king@canonical.com>

Hi,

On Thu, Mar 11, 2021 at 1:53 AM Colin King <colin.king@canonical.com> wrote:
>
> From: Colin Ian King <colin.king@canonical.com>
>
> The shifting of the u8 integer buf[3] by 24 bits to the left will
> be promoted to a 32 bit signed int and then sign-extended to a
> u64. In the event that the top bit of buf[3] is set then all
> then all the upper 32 bits of the u64 end up as also being set
> because of the sign-extension. Fix this by casting buf[i] to
> a u64 before the shift.
>
> Addresses-Coverity: ("Unintended sign extension")
> Fixes: 097eb1136ebb ("nvmem: core: Add functions to make number reading easy")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>  drivers/nvmem/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks! I had only tested the "u64" version to read smaller data and
store it in a u64. From my understanding of C rules, without your
patch it would have been even worse than just a sign extension though,
right? Shifting "buf[i]" by more than 32 bits would just not have
worked right.

In any case:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

  reply	other threads:[~2021-03-11 17:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11  9:53 [PATCH][next] nvmem: core: Fix unintentional sign extension issue Colin King
2021-03-11 17:12 ` Doug Anderson [this message]
2021-03-11 17:22   ` Colin Ian King
2021-03-11 17:50 ` Srinivas Kandagatla

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='CAD=FV=V5+GvMpD1FdX0-TJ=BFyyvST+oLR08pO7jL+h38G8PCw@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=colin.king@canonical.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.