kernel-janitors.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Colin King <colin.king@canonical.com>,
	"David S . Miller" <davem@davemloft.net>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	kernel-janitors@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] crypto: xts: use memmove to avoid overlapped memory copy
Date: Fri, 17 Jul 2020 05:59:54 +0000	[thread overview]
Message-ID: <CAMj1kXH9PHNNUMgwNUv8gBJDxs8w5Eta=AouKM7L=hMWNOQ=HQ@mail.gmail.com> (raw)
In-Reply-To: <20200717052139.GB2045@gondor.apana.org.au>

On Fri, 17 Jul 2020 at 08:21, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Jul 16, 2020 at 06:56:30PM +0300, Ard Biesheuvel wrote:
> > On Thu, 16 Jul 2020 at 18:29, Colin King <colin.king@canonical.com> wrote:
> > >
> > > From: Colin Ian King <colin.king@canonical.com>
> > >
> > > There is a memcpy that performs a potential overlapped memory copy
> > > from source b to destination b + 1.  Fix this by using the safer
> > > memmove instead.
> > >
> > > Addresses-Coverity: ("Overlapping buffer in memory copy")
> > > Fixes: 8083b1bf8163 ("crypto: xts - add support for ciphertext stealing")
> > > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > > ---
> > >  crypto/xts.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/crypto/xts.c b/crypto/xts.c
> > > index 3565f3b863a6..fa3e6e7b7043 100644
> > > --- a/crypto/xts.c
> > > +++ b/crypto/xts.c
> > > @@ -169,7 +169,7 @@ static int cts_final(struct skcipher_request *req,
> > >                                       offset - XTS_BLOCK_SIZE);
> > >
> > >         scatterwalk_map_and_copy(b, rctx->tail, 0, XTS_BLOCK_SIZE, 0);
> > > -       memcpy(b + 1, b, tail);
> > > +       memmove(b + 1, b, tail);
> >
> > This is a false positive: tail is guaranteed to be smaller than
> > sizeof(*b), so memmove() is unnecessary here.
> >
> > If changing to memcpy(&b[1], &b[0], tail) makes the warning go away, i
> > am fine with it, but otherwise we should just leave it as is.
>
> How about a comment perhaps?
>

Or change it to b[1] = b[0] (assuming the compiler allows struct
assignment in that way). This will always copy XTS_BLOCK_SIZE bytes,
but we have sufficient space, and it is probably more efficient  too
in most cases.


> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  reply	other threads:[~2020-07-17  5:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 15:29 [PATCH] crypto: xts: use memmove to avoid overlapped memory copy Colin King
2020-07-16 15:56 ` Ard Biesheuvel
2020-07-16 16:05   ` Colin Ian King
2020-07-17  5:21   ` Herbert Xu
2020-07-17  5:59     ` Ard Biesheuvel [this message]
2020-07-17  6:43       ` Herbert Xu

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='CAMj1kXH9PHNNUMgwNUv8gBJDxs8w5Eta=AouKM7L=hMWNOQ=HQ@mail.gmail.com' \
    --to=ardb@kernel.org \
    --cc=colin.king@canonical.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).