From: "J. Bruce Fields" <bfields@fieldses.org>
To: Scott Mayhew <smayhew@redhat.com>
Cc: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
jlayton@kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] sunrpc: fix 4 more call sites that were using stack memory with a scatterlist
Date: Fri, 15 Feb 2019 14:58:18 -0500 [thread overview]
Message-ID: <20190215195818.GB22354@fieldses.org> (raw)
In-Reply-To: <20190215184202.5537-1-smayhew@redhat.com>
Thanks! Applying for 5.0 and stable.
--b.
On Fri, Feb 15, 2019 at 01:42:02PM -0500, Scott Mayhew wrote:
> While trying to reproduce a reported kernel panic on arm64, I discovered
> that AUTH_GSS basically doesn't work at all with older enctypes on arm64
> systems with CONFIG_VMAP_STACK enabled. It turns out there still a few
> places using stack memory with scatterlists, causing krb5_encrypt() and
> krb5_decrypt() to produce incorrect results (or a BUG if CONFIG_DEBUG_SG
> is enabled).
>
> Tested with cthon on v4.0/v4.1/v4.2 with krb5/krb5i/krb5p using
> des3-cbc-sha1 and arcfour-hmac-md5.
>
> Signed-off-by: Scott Mayhew <smayhew@redhat.com>
> ---
> net/sunrpc/auth_gss/gss_krb5_seqnum.c | 49 +++++++++++++++++++++------
> 1 file changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/net/sunrpc/auth_gss/gss_krb5_seqnum.c b/net/sunrpc/auth_gss/gss_krb5_seqnum.c
> index fb6656295204..507105127095 100644
> --- a/net/sunrpc/auth_gss/gss_krb5_seqnum.c
> +++ b/net/sunrpc/auth_gss/gss_krb5_seqnum.c
> @@ -44,7 +44,7 @@ krb5_make_rc4_seq_num(struct krb5_ctx *kctx, int direction, s32 seqnum,
> unsigned char *cksum, unsigned char *buf)
> {
> struct crypto_sync_skcipher *cipher;
> - unsigned char plain[8];
> + unsigned char *plain;
> s32 code;
>
> dprintk("RPC: %s:\n", __func__);
> @@ -52,6 +52,10 @@ krb5_make_rc4_seq_num(struct krb5_ctx *kctx, int direction, s32 seqnum,
> if (IS_ERR(cipher))
> return PTR_ERR(cipher);
>
> + plain = kmalloc(8, GFP_NOFS);
> + if (!plain)
> + return -ENOMEM;
> +
> plain[0] = (unsigned char) ((seqnum >> 24) & 0xff);
> plain[1] = (unsigned char) ((seqnum >> 16) & 0xff);
> plain[2] = (unsigned char) ((seqnum >> 8) & 0xff);
> @@ -67,6 +71,7 @@ krb5_make_rc4_seq_num(struct krb5_ctx *kctx, int direction, s32 seqnum,
>
> code = krb5_encrypt(cipher, cksum, plain, buf, 8);
> out:
> + kfree(plain);
> crypto_free_sync_skcipher(cipher);
> return code;
> }
> @@ -77,12 +82,17 @@ krb5_make_seq_num(struct krb5_ctx *kctx,
> u32 seqnum,
> unsigned char *cksum, unsigned char *buf)
> {
> - unsigned char plain[8];
> + unsigned char *plain;
> + s32 code;
>
> if (kctx->enctype == ENCTYPE_ARCFOUR_HMAC)
> return krb5_make_rc4_seq_num(kctx, direction, seqnum,
> cksum, buf);
>
> + plain = kmalloc(8, GFP_NOFS);
> + if (!plain)
> + return -ENOMEM;
> +
> plain[0] = (unsigned char) (seqnum & 0xff);
> plain[1] = (unsigned char) ((seqnum >> 8) & 0xff);
> plain[2] = (unsigned char) ((seqnum >> 16) & 0xff);
> @@ -93,7 +103,9 @@ krb5_make_seq_num(struct krb5_ctx *kctx,
> plain[6] = direction;
> plain[7] = direction;
>
> - return krb5_encrypt(key, cksum, plain, buf, 8);
> + code = krb5_encrypt(key, cksum, plain, buf, 8);
> + kfree(plain);
> + return code;
> }
>
> static s32
> @@ -101,7 +113,7 @@ krb5_get_rc4_seq_num(struct krb5_ctx *kctx, unsigned char *cksum,
> unsigned char *buf, int *direction, s32 *seqnum)
> {
> struct crypto_sync_skcipher *cipher;
> - unsigned char plain[8];
> + unsigned char *plain;
> s32 code;
>
> dprintk("RPC: %s:\n", __func__);
> @@ -113,20 +125,28 @@ krb5_get_rc4_seq_num(struct krb5_ctx *kctx, unsigned char *cksum,
> if (code)
> goto out;
>
> + plain = kmalloc(8, GFP_NOFS);
> + if (!plain) {
> + code = -ENOMEM;
> + goto out;
> + }
> +
> code = krb5_decrypt(cipher, cksum, buf, plain, 8);
> if (code)
> - goto out;
> + goto out_plain;
>
> if ((plain[4] != plain[5]) || (plain[4] != plain[6])
> || (plain[4] != plain[7])) {
> code = (s32)KG_BAD_SEQ;
> - goto out;
> + goto out_plain;
> }
>
> *direction = plain[4];
>
> *seqnum = ((plain[0] << 24) | (plain[1] << 16) |
> (plain[2] << 8) | (plain[3]));
> +out_plain:
> + kfree(plain);
> out:
> crypto_free_sync_skcipher(cipher);
> return code;
> @@ -139,7 +159,7 @@ krb5_get_seq_num(struct krb5_ctx *kctx,
> int *direction, u32 *seqnum)
> {
> s32 code;
> - unsigned char plain[8];
> + unsigned char *plain;
> struct crypto_sync_skcipher *key = kctx->seq;
>
> dprintk("RPC: krb5_get_seq_num:\n");
> @@ -147,18 +167,25 @@ krb5_get_seq_num(struct krb5_ctx *kctx,
> if (kctx->enctype == ENCTYPE_ARCFOUR_HMAC)
> return krb5_get_rc4_seq_num(kctx, cksum, buf,
> direction, seqnum);
> + plain = kmalloc(8, GFP_NOFS);
> + if (!plain)
> + return -ENOMEM;
>
> if ((code = krb5_decrypt(key, cksum, buf, plain, 8)))
> - return code;
> + goto out;
>
> if ((plain[4] != plain[5]) || (plain[4] != plain[6]) ||
> - (plain[4] != plain[7]))
> - return (s32)KG_BAD_SEQ;
> + (plain[4] != plain[7])) {
> + code = (s32)KG_BAD_SEQ;
> + goto out;
> + }
>
> *direction = plain[4];
>
> *seqnum = ((plain[0]) |
> (plain[1] << 8) | (plain[2] << 16) | (plain[3] << 24));
>
> - return 0;
> +out:
> + kfree(plain);
> + return code;
> }
> --
> 2.17.2
prev parent reply other threads:[~2019-02-15 19:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 18:42 [PATCH] sunrpc: fix 4 more call sites that were using stack memory with a scatterlist Scott Mayhew
2019-02-15 19:58 ` J. Bruce Fields [this message]
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=20190215195818.GB22354@fieldses.org \
--to=bfields@fieldses.org \
--cc=anna.schumaker@netapp.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=smayhew@redhat.com \
--cc=trond.myklebust@hammerspace.com \
/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).