On Mon, 2016-12-05 at 20:34 +0800, Herbert Xu wrote: > On Fri, Dec 02, 2016 at 04:15:21PM -0800, Tim Chen wrote: > > > > Algorithms not compatible with mcryptd could be spawned by mcryptd > > with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" > > name construct. This causes mcryptd to crash the kernel if > > "alg" is incompatible and not intended to be used with mcryptd. > > > > A flag CRYPTO_ALG_MCRYPT is being added to mcryptd compatible > > algorithms' cra_flags. The compatability is checked when mcryptd spawn > > off an algorithm. > > > > Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2 > > Cc: stable@xxxxxxxxxxxxxxx > > Reported-by: Mikulas Patocka <mpatocka@xxxxxxxxxx> > > Tested-by: Megha Dey <megha.dey@xxxxxxxxxxxxxxx> > > Signed-off-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> > Tim, I think we should instead make mcryptd refuse to generate > a non-internal algorithm. This way the user would not be able > to access it at all since they can only request for non-internal > algorithms. > > Basically you want to check at the start of mcryptd_create_hash > that the INTERNAL bit is set on both the type and mask as returned > by crypto_get_attr_type. I have thought about that. However, not all internal algorithms are compatible with mcryptd. We can still have trouble if some random internal algorithm is paired with mcryptd. Tim -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
