mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: syzbot 
	<bot+3401d9494b9380f7244bcc7fec49680878fccba6@syzkaller.appspotmail.com>,
	davem@davemloft.net, herbert@gondor.apana.org.au,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: general protection fault in blkcipher_walk_done
Date: Tue, 28 Nov 2017 09:31:33 +0100	[thread overview]
Message-ID: <8642775.1nriSlZD2S@tauon.chronox.de> (raw)
In-Reply-To: <20171128075307.GA23413@zzz.localdomain>

Am Dienstag, 28. November 2017, 08:53:07 CET schrieb Eric Biggers:

Hi Eric,

> On Mon, Nov 27, 2017 at 09:37:38PM -0800, Eric Biggers wrote:
> > On Mon, Nov 27, 2017 at 10:56:47AM -0800, syzbot wrote:
> > > Hello,
> > > 
> > > syzkaller hit the following crash on
> > > 1ea8d039f9edcfefb20d8ddfe136930f6e551529
> > > git://git.cmpxchg.org/linux-mmots.git/master
> > > compiler: gcc (GCC) 7.1.1 20170620
> > > .config is attached
> > > Raw console output is attached.
> > > C reproducer is attached
> > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > > for information about syzkaller reproducers
> > 
> > Still happens on latest Linus tree (v4.15-rc1) with crypto/master merged
> > in.  It seems that _aead_recvmsg() is being confused by the operation
> > mode being changed from encryption to decryption while it has dropped the
> > socket lock in
> > af_alg_wait_for_data().  Here's a simplified reproducer:
> Stephan, why does af_alg_get_rsgl() call af_alg_wait_for_data()?  It's not
> actually reading anything from the "TX SGL" yet; it's just preparing the "RX
> SGL".  It seems to be in completely the wrong place.

I would disagree with this assertion: If there is no TX SGL to be processed, 
why should the kernel prepare already an RX SGL (and thus allocate memory)? 
The RX SGL should only have a very short life span, i.e. when there is real 
work to be done. If we are waiting for work, the kernel should not occupy 
resources that may or may not be used.

> And how exactly
> should the AEAD interface know when to wait anyway, given that someone
> could ask to encrypt 0 bytes to get the authentication tag for that?

This very issue is caught with af_alg_wait_for_data where the sleep is 
terminated or not even entered with " || !ctx->more". For AEAD you need to 
clear the MSG_MORE flag when you sent the last chunk of data.

See [1] for a test where a gcm(aes) encryption is performed with zero 
plaintext, zero AAD, zero expected ciphertext but where only the tag is 
calculated. 

[1] https://github.com/smuellerDD/libkcapi/blob/master/test/test.sh#L305
> 
> Eric



Ciao
Stephan

  reply	other threads:[~2017-11-28  8:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 18:56 syzbot
2017-11-28  5:37 ` Eric Biggers
2017-11-28  7:53   ` Eric Biggers
2017-11-28  8:31     ` Stephan Mueller [this message]
2017-11-28  9:03   ` Stephan Mueller
2017-11-28 21:33     ` [PATCH v2] crypto: AF_ALG - race-free access of encryption flag Stephan Müller
2017-11-28 22:40       ` Eric Biggers
2017-11-28 23:02       ` Herbert Xu
2017-11-29  6:48         ` Stephan Mueller
2017-11-29  7:10           ` Herbert Xu
2017-11-29  7:17             ` Stephan Mueller
2017-11-29 10:17               ` [PATCH] crypto: AF_ALG - wait for data at beginning of recvmsg Stephan Müller
2017-11-29 10:22                 ` Herbert Xu
2017-11-29 10:28                   ` Stephan Mueller
2017-11-29 10:42                     ` Herbert Xu
2017-11-29 11:02                       ` [PATCH v2] " Stephan Müller
2017-12-11 11:45                         ` Herbert Xu
2017-11-29 11:05             ` [PATCH v2] crypto: AF_ALG - race-free access of encryption flag Stephan Müller
2017-11-29 12:17               ` Herbert Xu
2017-12-11 19:10 ` general protection fault in blkcipher_walk_done 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=8642775.1nriSlZD2S@tauon.chronox.de \
    --to=smueller@chronox.de \
    --cc=bot+3401d9494b9380f7244bcc7fec49680878fccba6@syzkaller.appspotmail.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers3@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.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

Powered by JetHome