Date:   Wed, 20 Feb 2019 12:06:28 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Steffen Klassert <steffen.klassert@secunet.com>
Cc:     Eric Biggers <ebiggers3@gmail.com>, linux-crypto@vger.kernel.org,
        syzkaller-bugs@googlegroups.com, Eric Biggers <ebiggers@google.com>
Subject: Re: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation
Message-ID: <20190220040628.673rc2ffs7dxepu2@gondor.apana.org.au>
References: <20171230083744.vuclnbs677tj7pi2@gauss3.secunet.de>
 <20180310232231.19191-1-ebiggers3@gmail.com>
 <20180323002152.GA30497@gondor.apana.org.au>
 <20180408225528.GH685@sol.localdomain>
 <20180409085807.2cwvr5cocz6gfbmv@gauss3.secunet.de>
 <20180409190739.GC203367@gmail.com>
 <20180418053533.wuo6bj2okqdu2hrf@gauss3.secunet.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180418053533.wuo6bj2okqdu2hrf@gauss3.secunet.de>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Wed, Apr 18, 2018 at 07:35:33AM +0200, Steffen Klassert wrote:
> 
> Yes sure, I just wanted to know if it is worth to think about
> preventing template recursions. If there is a valid usecase,
> then we don't even need to think in this direction.
> 
> While I think each pcrypt instance should have it's own
> padata instance on the long run, it would be good to have
> a not so intrusive fix that can be backported to the stable
> trees.

Steffen, has there been any progress on this work?

We need to fix this soon or we'll have to disable pcrypt because
it is a security issue.

It's not just about nested templates either.  You can trigger
the same issue where a pcrypt instance over an AEAD algorithm
that uses a fallback which also happens to be pcrypt.

Cheers,
-- 
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