On Mon, Jul 06, 2026 at 08:20:10PM +0200, Milan Broz wrote: > On 7/5/26 8:44 PM, Eric Biggers wrote: > > Add "xts(camellia)", "xts(serpent)", and "xts(twofish)" to the allowlist > > for af_alg_restrict=1. These niche AES alternatives have continued to > > see rare but persistent use via cryptsetup, which has historically > > relied on the AF_ALG support for these ciphers in XTS mode for > > performing the keyslot encryption. (cryptsetup v2.8.7 and later fall > > back to a temporary dm-crypt mapping, but that requires root.) > > > > Signed-off-by: Eric Biggers <[email protected]> > > --- > > crypto/algif_skcipher.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c > > index 2b8069667974..49ae779b3b6b 100644 > > --- a/crypto/algif_skcipher.c > > +++ b/crypto/algif_skcipher.c > > @@ -45,6 +45,9 @@ static const struct af_alg_allowlist_entry > > skcipher_allowlist[] = { > > { "ecb(des)", true }, /* iwd */ > > { "hctr2(aes)", false }, /* cryptsetup */ > > { "xts(aes)", false }, /* cryptsetup benchmark */ > > + { "xts(camellia)", false }, /* cryptsetup */ > > + { "xts(serpent)", false }, /* cryptsetup */ > > + { "xts(twofish)", false }, /* cryptsetup */ > > {}, > > Well, if we are going this way, I would also add Aria and SM4 > (currently usable only in cryptsetup main branch).
I'm adding these three because they seem to have a history of occasional use, as can be seen by web search results including their mentions in various forums, documentation, etc. So I worry about breaking users of them who upgrade their kernel and still have cryptsetup < 2.8.7. It doesn't seem like the same as true of aria-xts or sm4-xts. And as you said they are usable only on the cryptsetup main branch -- which I understand now consistently uses the fallback to a temporary dm-crypt mapping (at least when run as root). So perhaps we don't actually need to allow "xts(aria)" and "xts(sm4)" as well? The point isn't to add things that could theoretically be used, but rather add the minimum set that's needed to keep actual existing users working. > There is another user of AF_ALG hash, hardlink in util-linux, see > https://github.com/util-linux/util-linux/blob/master/lib/fileeq.c The AF_ALG use in 'hardlink' is unnecessary and has just been causing problems (https://sporks.space/2026/05/19/chasing-down-why-installing-the-kernel-segfaulted/). Fortunately, it's not a hard dependency, as it already has a working runtime fallback. This was discussed on the util-linux issue tracker as well, and I understand the AF_ALG use is planned to be removed. - Eric
