On 01/04/2016 05:35 AM, Herbert Xu wrote: > On Sun, Jan 03, 2016 at 10:42:28AM +0100, Milan Broz wrote: >> >> 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.) > > OK please try these two patches (warning, totally untested). Well, it is not much better. I had to apply another two patches that are not mentioned and are not in your tree yet before it: crypto: af_alg - Disallow bind_setkey_... after accept(2) crypto: use-after-free in alg_bind then it at least compiles correctly. skcipher works, But I still see two compatibility problems: - hmac() is now failing the same way (SETKEY after accept()) (I initially tested without two patches above, these are not in linux-next yet.) This breaks all cryptsetup TrueCrypt support (and moreover all systems if kernel crypto API is set as a default vcrypto backend - but that's not default). - cipher_null before worked without setkey, now it requires to set key (either before or after accept(). This was actually probably bad workaround in cryptsetup, anyway it will now cause old cryptsetup-reencrypt tool failing with your patches. (Try "cryptsetup benchmark -c cipher_null-ecb". I am not sure what to do here, but not requiring setkey for "cipher" that has no key internally seems ok for me...) As I said, I'll fix it in cryptsetup upstream but we are breaking a lot of existing systems. Isn't there better way, how to fix it? Milan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
