linux.git/crypto/algif_skcipher.c, branch master

crypto: af_alg - Replace 'bool privileged' with flags

2026-08-10T08:34:21+00:00

It isn't obvious what false/true mean at the definition sites, so let's replace it with flags instead. Also flip the polarity to make the default zero-initialized value be the secure (privileged-only) value. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: af_alg - Make cbc(paes) privileged-only

2026-08-10T08:34:21+00:00

So far the only reported use cases for cbc(paes) have involved processes running as root. Therefore, make af_alg_restrict=1 allow only privileged use of this algorithm for now. Fixes: 947d62c09436 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6") Signed-off-by: Eric Biggers Reviewed-by: Richard Weinberger Signed-off-by: Herbert Xu

Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2026-07-31T07:28:24+00:00

Merge crypto tree to pick up the af_alg cbc(paes) patch. In the merge commit add cbc(paes) to the algorithm white-list.

crypto: af_alg - Allow cbc(paes)

2026-07-30T07:44:21+00:00

Commit 7524070f26d8 ("crypto: af_alg - Drop support for off-CPU cryptography") breaks a special use case. The cbc-paes-caam driver implements the algorithm cbc(paes), it offers a way to use AES in CBC mode with key material unknown to userspace. Instead of an AES key a CAAM BLOB is passed to the kernel. So, this crypto operation cannot be implemented in a userspace library and needs always help from the kernel. Explicitly allow this use case. Cc: Demi Marie Obenour Suggested-by: Eric Biggers Fixes: 7524070f26d8 ("crypto: af_alg - Drop support for off-CPU cryptography") Signed-off-by: Richard Weinberger Reviewed-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: af_alg - Allow additional ciphers for cryptsetup

2026-07-17T08:09:21+00:00

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 Signed-off-by: Herbert Xu

crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1

2026-07-05T05:27:15+00:00

AF_ALG is a frequent source of vulnerabilities and a maintenance nightmare. It exposes far more functionality to userspace than ever should have been exposed, especially to unprivileged processes. Recent exploits have targeted kernel internal implementation details like "authencesn" that have zero use case for userspace access. Fortunately, AF_ALG is rarely used in practice, as userspace crypto libraries exist. And when it is used, only some functionality is known to be used, and many users are known to hold capabilities already. iwd for example requires CAP_NET_ADMIN and has a known algorithm list (https://lore.kernel.org/linux-crypto/bcbbef00-5881-421b-8892-7be6c04b832d@gmail.com/). Thus, let's restrict the set of allowed algorithms by default, depending on the capabilities held. Add a sysctl /proc/sys/crypto/af_alg_restrict with meaning: 0: unrestricted 1: limited functionality 2: completely disabled Set the default value to 1, which enables an algorithm allowlist for unprivileged processes and a slightly longer allowlist for privileged processes. Note that the list may be tweaked in the future. However, the common use cases such as iwd and bluez are taken into account already. I've tested that iwd still works with the default value of 1. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: af_alg - Drop support for off-CPU cryptography

2026-05-29T06:05:30+00:00

AF_ALG is deprecated and exposed to unprivileged userspace. Only use the least buggy algorithm implementations: the pure software ones. This removes one of the main advantages of AF_ALG, which is the ability to use it with off-CPU accelerators. However, using off-CPU accelerators has huge overheads, both in performance and attack surface. I have yet to see real-world, performance-critical workloads where using an accelerator via AF_ALG is actually a win over doing cryptography in userspace. If using an off-CPU accelerator really does turn out to be a win, a new API should be developed that is actually a good fit for it. Signed-off-by: Demi Marie Obenour Signed-off-by: Herbert Xu

net: Remove support for AIO on sockets

2026-05-29T06:05:30+00:00

The only user of msg->msg_iocb was AF_ALG, but that's deprecated. It can be removed entirely at the cost of only supporting synchronous operations. This doesn't break userspace, which will silently block (for a bounded amount of time) in io_submit instead of operating asynchronously. This also makes struct msghdr smaller, helping every other caller of sendmsg(). Signed-off-by: Demi Marie Obenour Acked-by: Jakub Kicinski Signed-off-by: Herbert Xu

crypto: af_alg - limit RX SG extraction by receive buffer budget

2026-04-03T00:54:14+00:00

Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget. af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request. If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero. Fixes: e870456d8e7c8d57c059ea479b5aadbb55ff4c3a ("crypto: algif_skcipher - overhaul memory management") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Douya Le Signed-off-by: Ren Wei Signed-off-by: Herbert Xu

crypto: algif_aead - Revert to operating out-of-place

2026-03-31T08:11:47+00:00

This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly. Fixes: 72548b093ee3 ("crypto: algif_aead - copy AAD from src to dst") Reported-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Herbert Xu