| Message ID | 20151225074005.GA14690@gondor.apana.org.au (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Herbert Xu |
| Headers | show |
On Fri, Dec 25, 2015 at 8:40 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > Dmitry Vyukov <dvyukov@google.com> wrote: >> >> I am testing with your two patches: >> crypto: algif_skcipher - Use new skcipher interface >> crypto: algif_skcipher - Require setkey before accept(2) >> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23). > > You sent the email to everyone on the original CC list except me. > Please don't do that. Hi Herbert, My email client just followed instructions in your email. You've said to Reply-to: syzkaller@googlegroups.com. This version of the patch does fix the crash. Tested-by: Dmitry Vyukov <dvyukov@google.com> However, crypto is still considerably unstable. I will post reports that I see separately. >> Now the following program causes a bunch of use-after-frees and them >> kills kernel: > > Yes there is an obvious bug in the patch that Julia Lawall has > responded to in another thread. Here is a fixed version. > > ---8<-- > Some cipher implementations will crash if you try to use them > without calling setkey first. This patch adds a check so that > the accept(2) call will fail with -ENOKEY if setkey hasn't been > done on the socket yet. > > Cc: stable@vger.kernel.org > Reported-by: Dmitry Vyukov <dvyukov@google.com> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > > diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c > index 5c756b3..f4431bc 100644 > --- a/crypto/algif_skcipher.c > +++ b/crypto/algif_skcipher.c > @@ -31,6 +31,11 @@ struct skcipher_sg_list { > struct scatterlist sg[0]; > }; > > +struct skcipher_tfm { > + struct crypto_skcipher *skcipher; > + bool has_key; > +}; > + > struct skcipher_ctx { > struct list_head tsgl; > struct af_alg_sgl rsgl; > @@ -750,17 +755,41 @@ static struct proto_ops algif_skcipher_ops = { > > static void *skcipher_bind(const char *name, u32 type, u32 mask) > { > - return crypto_alloc_skcipher(name, type, mask); > + struct skcipher_tfm *tfm; > + struct crypto_skcipher *skcipher; > + > + tfm = kzalloc(sizeof(*tfm), GFP_KERNEL); > + if (!tfm) > + return ERR_PTR(-ENOMEM); > + > + skcipher = crypto_alloc_skcipher(name, type, mask); > + if (IS_ERR(skcipher)) { > + kfree(tfm); > + return ERR_CAST(skcipher); > + } > + > + tfm->skcipher = skcipher; > + > + return tfm; > } > > static void skcipher_release(void *private) > { > - crypto_free_skcipher(private); > + struct skcipher_tfm *tfm = private; > + > + crypto_free_skcipher(tfm->skcipher); > + kfree(tfm); > } > > static int skcipher_setkey(void *private, const u8 *key, unsigned int keylen) > { > - return crypto_skcipher_setkey(private, key, keylen); > + struct skcipher_tfm *tfm = private; > + int err; > + > + err = crypto_skcipher_setkey(tfm->skcipher, key, keylen); > + tfm->has_key = !err; > + > + return err; > } > > static void skcipher_wait(struct sock *sk) > @@ -792,20 +821,25 @@ static int skcipher_accept_parent(void *private, struct sock *sk) > { > struct skcipher_ctx *ctx; > struct alg_sock *ask = alg_sk(sk); > - unsigned int len = sizeof(*ctx) + crypto_skcipher_reqsize(private); > + struct skcipher_tfm *tfm = private; > + struct crypto_skcipher *skcipher = tfm->skcipher; > + unsigned int len = sizeof(*ctx) + crypto_skcipher_reqsize(skcipher); > + > + if (!tfm->has_key) > + return -ENOKEY; > > ctx = sock_kmalloc(sk, len, GFP_KERNEL); > if (!ctx) > return -ENOMEM; > > - ctx->iv = sock_kmalloc(sk, crypto_skcipher_ivsize(private), > + ctx->iv = sock_kmalloc(sk, crypto_skcipher_ivsize(skcipher), > GFP_KERNEL); > if (!ctx->iv) { > sock_kfree_s(sk, ctx, len); > return -ENOMEM; > } > > - memset(ctx->iv, 0, crypto_skcipher_ivsize(private)); > + memset(ctx->iv, 0, crypto_skcipher_ivsize(skcipher)); > > INIT_LIST_HEAD(&ctx->tsgl); > ctx->len = len; > @@ -818,7 +852,7 @@ static int skcipher_accept_parent(void *private, struct sock *sk) > > ask->private = ctx; > > - skcipher_request_set_tfm(&ctx->req, private); > + skcipher_request_set_tfm(&ctx->req, skcipher); > skcipher_request_set_callback(&ctx->req, CRYPTO_TFM_REQ_MAY_BACKLOG, > af_alg_complete, &ctx->completion); > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups "syzkaller" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com. > To post to this group, send email to syzkaller@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/20151225074005.GA14690%40gondor.apana.org.au. > For more options, visit https://groups.google.com/d/optout. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dmitry Vyukov <dvyukov@google.com> wrote: > > My email client just followed instructions in your email. You've said > to Reply-to: syzkaller@googlegroups.com. I did not set this Reply-To header. It's most likely set by your broken Google Groups setup. So either you should start actually replying to my email address or your future emails will most likely not be read by me. Cheers,
On 12/25/2015 08:40 AM, Herbert Xu wrote: > Dmitry Vyukov <dvyukov@google.com> wrote: >> >> I am testing with your two patches: >> crypto: algif_skcipher - Use new skcipher interface >> crypto: algif_skcipher - Require setkey before accept(2) >> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23). > > You sent the email to everyone on the original CC list except me. > Please don't do that. > >> Now the following program causes a bunch of use-after-frees and them >> kills kernel: > > Yes there is an obvious bug in the patch that Julia Lawall has > responded to in another thread. Here is a fixed version. > > ---8<-- > Some cipher implementations will crash if you try to use them > without calling setkey first. This patch adds a check so that > the accept(2) call will fail with -ENOKEY if setkey hasn't been > done on the socket yet. Hi Herbert, this patch breaks userspace in cryptsetup... We use algif_skcipher in cryptsetup (for years, even before there was Stephan's library) and with this patch applied I see fail in ALG_SET_IV call (patch from your git). I can fix it upstream, but for thousands of installations it will be broken (for LUKS there is a fallback, cor TrueCrypt compatible devices it will be unusable. Also people who configured kernel crypto API as default backend will have non-working cryptsetup). Is it really thing for stable branch? Milan > > Cc: stable@vger.kernel.org > Reported-by: Dmitry Vyukov <dvyukov@google.com> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > > diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c > index 5c756b3..f4431bc 100644 > --- a/crypto/algif_skcipher.c > +++ b/crypto/algif_skcipher.c > @@ -31,6 +31,11 @@ struct skcipher_sg_list { > struct scatterlist sg[0]; > }; > > +struct skcipher_tfm { > + struct crypto_skcipher *skcipher; > + bool has_key; > +}; > + > struct skcipher_ctx { > struct list_head tsgl; > struct af_alg_sgl rsgl; > @@ -750,17 +755,41 @@ static struct proto_ops algif_skcipher_ops = { > > static void *skcipher_bind(const char *name, u32 type, u32 mask) > { > - return crypto_alloc_skcipher(name, type, mask); > + struct skcipher_tfm *tfm; > + struct crypto_skcipher *skcipher; > + > + tfm = kzalloc(sizeof(*tfm), GFP_KERNEL); > + if (!tfm) > + return ERR_PTR(-ENOMEM); > + > + skcipher = crypto_alloc_skcipher(name, type, mask); > + if (IS_ERR(skcipher)) { > + kfree(tfm); > + return ERR_CAST(skcipher); > + } > + > + tfm->skcipher = skcipher; > + > + return tfm; > } > > static void skcipher_release(void *private) > { > - crypto_free_skcipher(private); > + struct skcipher_tfm *tfm = private; > + > + crypto_free_skcipher(tfm->skcipher); > + kfree(tfm); > } > > static int skcipher_setkey(void *private, const u8 *key, unsigned int keylen) > { > - return crypto_skcipher_setkey(private, key, keylen); > + struct skcipher_tfm *tfm = private; > + int err; > + > + err = crypto_skcipher_setkey(tfm->skcipher, key, keylen); > + tfm->has_key = !err; > + > + return err; > } > > static void skcipher_wait(struct sock *sk) > @@ -792,20 +821,25 @@ static int skcipher_accept_parent(void *private, struct sock *sk) > { > struct skcipher_ctx *ctx; > struct alg_sock *ask = alg_sk(sk); > - unsigned int len = sizeof(*ctx) + crypto_skcipher_reqsize(private); > + struct skcipher_tfm *tfm = private; > + struct crypto_skcipher *skcipher = tfm->skcipher; > + unsigned int len = sizeof(*ctx) + crypto_skcipher_reqsize(skcipher); > + > + if (!tfm->has_key) > + return -ENOKEY; > > ctx = sock_kmalloc(sk, len, GFP_KERNEL); > if (!ctx) > return -ENOMEM; > > - ctx->iv = sock_kmalloc(sk, crypto_skcipher_ivsize(private), > + ctx->iv = sock_kmalloc(sk, crypto_skcipher_ivsize(skcipher), > GFP_KERNEL); > if (!ctx->iv) { > sock_kfree_s(sk, ctx, len); > return -ENOMEM; > } > > - memset(ctx->iv, 0, crypto_skcipher_ivsize(private)); > + memset(ctx->iv, 0, crypto_skcipher_ivsize(skcipher)); > > INIT_LIST_HEAD(&ctx->tsgl); > ctx->len = len; > @@ -818,7 +852,7 @@ static int skcipher_accept_parent(void *private, struct sock *sk) > > ask->private = ctx; > > - skcipher_request_set_tfm(&ctx->req, private); > + skcipher_request_set_tfm(&ctx->req, skcipher); > skcipher_request_set_callback(&ctx->req, CRYPTO_TFM_REQ_MAY_BACKLOG, > af_alg_complete, &ctx->completion); > > -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/02/2016 12:52 PM, Milan Broz wrote: > On 12/25/2015 08:40 AM, Herbert Xu wrote: >> Dmitry Vyukov <dvyukov@google.com> wrote: >>> >>> I am testing with your two patches: >>> crypto: algif_skcipher - Use new skcipher interface >>> crypto: algif_skcipher - Require setkey before accept(2) >>> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23). >> >> You sent the email to everyone on the original CC list except me. >> Please don't do that. >> >>> Now the following program causes a bunch of use-after-frees and them >>> kills kernel: >> >> Yes there is an obvious bug in the patch that Julia Lawall has >> responded to in another thread. Here is a fixed version. >> >> ---8<-- >> Some cipher implementations will crash if you try to use them >> without calling setkey first. This patch adds a check so that >> the accept(2) call will fail with -ENOKEY if setkey hasn't been >> done on the socket yet. > > > Hi Herbert, > > this patch breaks userspace in cryptsetup... > > We use algif_skcipher in cryptsetup (for years, even before > there was Stephan's library) and with this patch applied > I see fail in ALG_SET_IV call (patch from your git). (Obviously this was because of failing accept() call here, not set_iv.) > > I can fix it upstream, but for thousands of installations it will > be broken (for LUKS there is a fallback, cor TrueCrypt compatible devices > it will be unusable. Also people who configured kernel crypto API as default > backend will have non-working cryptsetup). > > Is it really thing for stable branch? Also how it is supposed to work for cipher_null, where there is no key? Why it should call set_key if it is noop? (and set key length 0 is not possible). (We are using cipher_null for testing and for offline re-encryption tool to create temporary "fake" header for not-yet encrypted device...) Milan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Samstag, 2. Januar 2016, 15:41:34 schrieb Milan Broz: Hi Milan, > On 01/02/2016 12:52 PM, Milan Broz wrote: > > On 12/25/2015 08:40 AM, Herbert Xu wrote: > >> Dmitry Vyukov <dvyukov@google.com> wrote: > >>> I am testing with your two patches: > >>> crypto: algif_skcipher - Use new skcipher interface > >>> crypto: algif_skcipher - Require setkey before accept(2) > >>> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23). > >> > >> You sent the email to everyone on the original CC list except me. > >> Please don't do that. > >> > >>> Now the following program causes a bunch of use-after-frees and them > >> > >>> kills kernel: > >> Yes there is an obvious bug in the patch that Julia Lawall has > >> responded to in another thread. Here is a fixed version. > >> > >> ---8<-- > >> Some cipher implementations will crash if you try to use them > >> without calling setkey first. This patch adds a check so that > >> the accept(2) call will fail with -ENOKEY if setkey hasn't been > >> done on the socket yet. > > > > Hi Herbert, > > > > this patch breaks userspace in cryptsetup... > > > > We use algif_skcipher in cryptsetup (for years, even before > > there was Stephan's library) and with this patch applied > > I see fail in ALG_SET_IV call (patch from your git). > > (Obviously this was because of failing accept() call here, not set_iv.) > > > I can fix it upstream, but for thousands of installations it will > > be broken (for LUKS there is a fallback, cor TrueCrypt compatible devices > > it will be unusable. Also people who configured kernel crypto API as > > default backend will have non-working cryptsetup). > > > > Is it really thing for stable branch? > > Also how it is supposed to work for cipher_null, where there is no key? > Why it should call set_key if it is noop? (and set key length 0 is not > possible). > > (We are using cipher_null for testing and for offline re-encryption tool > to create temporary "fake" header for not-yet encrypted device...) The change implies that any setkey or set IV operations (i.e. any operations on the tfmfd) are done before the opfd(s) are created with one or more accept calls. Thus, after a bind that returns the tfmfd, the setkey and setiv operations shall be called. This is followed by accept. If you change the order of invocations in your code, it should work. > > Milan
On 01/02/2016 09:03 PM, Stephan Mueller wrote: > Am Samstag, 2. Januar 2016, 15:41:34 schrieb Milan Broz: > > Hi Milan, > ... >>> Hi Herbert, >>> >>> this patch breaks userspace in cryptsetup... >>> >>> We use algif_skcipher in cryptsetup (for years, even before >>> there was Stephan's library) and with this patch applied >>> I see fail in ALG_SET_IV call (patch from your git). >> >> (Obviously this was because of failing accept() call here, not set_iv.) >> >>> I can fix it upstream, but for thousands of installations it will >>> be broken (for LUKS there is a fallback, cor TrueCrypt compatible devices >>> it will be unusable. Also people who configured kernel crypto API as >>> default backend will have non-working cryptsetup). >>> >>> Is it really thing for stable branch? >> >> Also how it is supposed to work for cipher_null, where there is no key? >> Why it should call set_key if it is noop? (and set key length 0 is not >> possible). >> >> (We are using cipher_null for testing and for offline re-encryption tool >> to create temporary "fake" header for not-yet encrypted device...) > > The change implies that any setkey or set IV operations (i.e. any operations > on the tfmfd) are done before the opfd(s) are created with one or more accept > calls. > > Thus, after a bind that returns the tfmfd, the setkey and setiv operations > shall be called. This is followed by accept. If you change the order of > invocations in your code, it should work. Hi, I already changed it in cryptsetup upstream this way. But I cannot change thousands of cryptsetup installations that are actively using that code. This is clear userspace breakage which should not happen this way. (Moreover it still doesn't work for cipher_null that has min/max key size 0.) Milan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote: > > But I cannot change thousands of cryptsetup installations that are actively using that code. > This is clear userspace breakage which should not happen this way. I'll try to add some compatibility code for your case, assuming your modus operandi is accept(2) followed by a single setkey before proceeding to encryption/decryption. > (Moreover it still doesn't work for cipher_null that has min/max key size 0.) Setkey works just fine on cipher_null. Cheers,
On 01/03/2016 02:31 AM, Herbert Xu wrote: > On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote: >> >> But I cannot change thousands of cryptsetup installations that are actively using that code. >> This is clear userspace breakage which should not happen this way. > > I'll try to add some compatibility code for your case, assuming > your modus operandi is accept(2) followed by a single setkey before > proceeding to encryption/decryption. Hi, yes, basically it prepares socket()/bind()/accept() and then it calls setkey once. (I'll try to fix in next releases to call setkey first though.) I am doing exactly the same for AF_ALG HMAC (hmac(<hash>) key, does this requirement for order if accept/setkey applies there as well? (It is not enforced yet.) Anyway, you can easily simulate that skcipher API call just with running "cryptsetup benchmark" (with accept() patch it will print N/A for all ciphers while without patch it measures some more-or-less magic performance numbers :) > >> (Moreover it still doesn't work for cipher_null that has min/max key size 0.) > > Setkey works just fine on cipher_null. Yes, it works if ALG_SET_KEY is set to zero-length key. I just re-introduced old bug to code, sorry. Thanks! Milan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c index 5c756b3..f4431bc 100644 --- a/crypto/algif_skcipher.c +++ b/crypto/algif_skcipher.c @@ -31,6 +31,11 @@ struct skcipher_sg_list { struct scatterlist sg[0]; }; +struct skcipher_tfm { + struct crypto_skcipher *skcipher; + bool has_key; +}; + struct skcipher_ctx { struct list_head tsgl; struct af_alg_sgl rsgl; @@ -750,17 +755,41 @@ static struct proto_ops algif_skcipher_ops = { static void *skcipher_bind(const char *name, u32 type, u32 mask) { - return crypto_alloc_skcipher(name, type, mask); + struct skcipher_tfm *tfm; + struct crypto_skcipher *skcipher; + + tfm = kzalloc(sizeof(*tfm), GFP_KERNEL); + if (!tfm) + return ERR_PTR(-ENOMEM); + + skcipher = crypto_alloc_skcipher(name, type, mask); + if (IS_ERR(skcipher)) { + kfree(tfm); + return ERR_CAST(skcipher); + } + + tfm->skcipher = skcipher; + + return tfm; } static void skcipher_release(void *private) { - crypto_free_skcipher(private); + struct skcipher_tfm *tfm = private; + + crypto_free_skcipher(tfm->skcipher); + kfree(tfm); } static int skcipher_setkey(void *private, const u8 *key, unsigned int keylen) { - return crypto_skcipher_setkey(private, key, keylen); + struct skcipher_tfm *tfm = private; + int err; + + err = crypto_skcipher_setkey(tfm->skcipher, key, keylen); + tfm->has_key = !err; + + return err; } static void skcipher_wait(struct sock *sk) @@ -792,20 +821,25 @@ static int skcipher_accept_parent(void *private, struct sock *sk) { struct skcipher_ctx *ctx; struct alg_sock *ask = alg_sk(sk); - unsigned int len = sizeof(*ctx) + crypto_skcipher_reqsize(private); + struct skcipher_tfm *tfm = private; + struct crypto_skcipher *skcipher = tfm->skcipher; + unsigned int len = sizeof(*ctx) + crypto_skcipher_reqsize(skcipher); + + if (!tfm->has_key) + return -ENOKEY; ctx = sock_kmalloc(sk, len, GFP_KERNEL); if (!ctx) return -ENOMEM; - ctx->iv = sock_kmalloc(sk, crypto_skcipher_ivsize(private), + ctx->iv = sock_kmalloc(sk, crypto_skcipher_ivsize(skcipher), GFP_KERNEL); if (!ctx->iv) { sock_kfree_s(sk, ctx, len); return -ENOMEM; } - memset(ctx->iv, 0, crypto_skcipher_ivsize(private)); + memset(ctx->iv, 0, crypto_skcipher_ivsize(skcipher)); INIT_LIST_HEAD(&ctx->tsgl); ctx->len = len; @@ -818,7 +852,7 @@ static int skcipher_accept_parent(void *private, struct sock *sk) ask->private = ctx; - skcipher_request_set_tfm(&ctx->req, private); + skcipher_request_set_tfm(&ctx->req, skcipher); skcipher_request_set_callback(&ctx->req, CRYPTO_TFM_REQ_MAY_BACKLOG, af_alg_complete, &ctx->completion);