From: Arnd Bergmann <arnd@arndb.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net, "Krzysztof Hałasa" <khalasa@piap.pl>
Subject: [PATCH] crypto: ixp4xx: avoid uninitialized variable use
Date: Mon, 18 Jan 2016 16:40:15 +0100 [thread overview]
Message-ID: <4569235.PkyVAB6DSj@wuerfel> (raw)
The move to the new AEAD interface introduced a path through the
aead_perform() function in the ixp4xx_crypto driver that leaves
lastlen uninitialized, as gcc warns:
crypto/ixp4xx_crypto.c:1072:5: error: 'lastlen' may be used uninitialized in this function [-Werror=maybe-uninitialized]
crypto/ixp4xx_crypto.c: In function 'aead_perform':
if (unlikely(lastlen < authsize)) {
I don't really understand what the code does, but the warning
appears to be correct, and this is my best guess at how it
should behave instead: I'm introducing a temporary variable
that indicates whether we need to allocate an extra buffer
or not, and defaults that variable to 'false', so we only
allocate the buffer if one of the cases happen where we know
that "lastlen < authsize".
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: d7295a8dc965 ("crypto: ixp4xx - Convert to new AEAD interface")
---
Hi Herbert,
It was one of your patches that introduced the warning, so you may
be able to come up with a better fix than I did. Please see this as
a bug report. I have applied it in my ARM randconfig test tree to shut
up the warning for now.
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index e52496a172d0..00c39a5aa4c7 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -999,6 +999,7 @@ static int aead_perform(struct aead_request *req, int encrypt,
GFP_KERNEL : GFP_ATOMIC;
enum dma_data_direction src_direction = DMA_BIDIRECTIONAL;
unsigned int lastlen;
+ bool shortbuf = false;
if (qmgr_stat_full(SEND_QID))
return -EAGAIN;
@@ -1052,6 +1053,8 @@ static int aead_perform(struct aead_request *req, int encrypt,
if (lastlen >= authsize)
crypt->icv_rev_aes = buf->phys_addr +
buf->buf_len - authsize;
+ else
+ shortbuf = true;
}
}
@@ -1067,9 +1070,11 @@ static int aead_perform(struct aead_request *req, int encrypt,
if (lastlen >= authsize)
crypt->icv_rev_aes = buf->phys_addr +
buf->buf_len - authsize;
+ else
+ shortbuf = true;
}
- if (unlikely(lastlen < authsize)) {
+ if (unlikely(shortbuf)) {
/* The 12 hmac bytes are scattered,
* we need to copy them into a safe buffer */
req_ctx->hmac_virt = dma_pool_alloc(buffer_pool, flags,
next reply other threads:[~2016-01-18 15:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 15:40 Arnd Bergmann [this message]
2016-01-19 1:00 ` [PATCH] crypto: ixp4xx: avoid uninitialized variable use Herbert Xu
2016-01-19 15:03 ` Arnd Bergmann
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=4569235.PkyVAB6DSj@wuerfel \
--to=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=khalasa@piap.pl \
--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