linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-crypto@vger.kernel.org
Subject: potential underfow in crypto/lrw.c setkey() setkey
Date: Thu, 9 May 2019 14:06:22 +0300	[thread overview]
Message-ID: <20190509110622.GA15580@mwanda> (raw)

crypto/lrw.c
    72  static int setkey(struct crypto_skcipher *parent, const u8 *key,
    73                    unsigned int keylen)
    74  {
    75          struct priv *ctx = crypto_skcipher_ctx(parent);
    76          struct crypto_skcipher *child = ctx->child;
    77          int err, bsize = LRW_BLOCK_SIZE;
    78          const u8 *tweak = key + keylen - bsize;
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Smatch thinks that keylen is user controlled from zero to some upper
bound.  How do we know it's >= LRW_BLOCK_SIZE (16)?

I find the crypto code sort of hard to follow...  There are a bunch of
setkey pointers and they're sometimes called recursively.  Is there
some trick or hints?

    79          be128 tmp = { 0 };
    80          int i;
    81  
    82          crypto_skcipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
    83          crypto_skcipher_set_flags(child, crypto_skcipher_get_flags(parent) &
    84                                           CRYPTO_TFM_REQ_MASK);
    85          err = crypto_skcipher_setkey(child, key, keylen - bsize);
    86          crypto_skcipher_set_flags(parent, crypto_skcipher_get_flags(child) &
    87                                            CRYPTO_TFM_RES_MASK);
    88          if (err)
    89                  return err;
    90  
    91          if (ctx->table)
    92                  gf128mul_free_64k(ctx->table);
    93  
    94          /* initialize multiplication table for Key2 */
    95          ctx->table = gf128mul_init_64k_bbe((be128 *)tweak);
    96          if (!ctx->table)
    97                  return -ENOMEM;
    98  
    99          /* initialize optimization table */
   100          for (i = 0; i < 128; i++) {
   101                  setbit128_bbe(&tmp, i);
   102                  ctx->mulinc[i] = tmp;
   103                  gf128mul_64k_bbe(&ctx->mulinc[i], ctx->table);
   104          }
   105  
   106          return 0;
   107  }

regards,
dan carpenter

             reply	other threads:[~2019-05-09 11:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09 11:06 Dan Carpenter [this message]
2019-05-10  4:03 ` potential underfow in crypto/lrw.c setkey() setkey Eric Biggers

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=20190509110622.GA15580@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=linux-crypto@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).