| Message ID | 20211003181413.12465-3-nstange@suse.de (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | crypto: api - priorize tested algorithms in lookup | expand |
diff --git a/crypto/crypto_user_base.c b/crypto/crypto_user_base.c index 3fa20f12989f..a9c06cd98a8c 100644 --- a/crypto/crypto_user_base.c +++ b/crypto/crypto_user_base.c @@ -352,6 +352,9 @@ static int crypto_add_alg(struct sk_buff *skb, struct nlmsghdr *nlh, if (priority && !exact) return -EINVAL; + if ((p->cru_type ^ p->cru_mask) & CRYPTO_ALG_TESTED) + return -EINVAL; + alg = crypto_alg_match(p, exact); if (alg) { crypto_mod_put(alg);
Currently it's possible for userspace to specify any combination of ->cru_type and ->cru_mask with respect to CRYTPO_ALG_TESTED via the CRYPTO_MSG_NEWALG crypto_user interface. As these are passed onwards to crypto_larval_lookup() unmodified as 'mask' and 'type' parameters eventually, this can lead to the creation of obscure lookup larvals like e.g. (mask & CRYTPO_ALG_TESTED) but not (type & CRYTPO_ALG_TESTED) or the other way around. Userspace should have no business in asking for untested algorithms. Make crypto_user's crypto_add_alg() reject nonsensical combinations of ->cru_type and ->cru_mask with respect to CRYTPO_ALG_TESTED with -EINVAL. Note that CRYTPO_ALG_TESTED not being set in either of mask and type is considered equivalent to that flag being set in both and these two combinations are the only ones supported as of now. Signed-off-by: Nicolai Stange <nstange@suse.de> --- crypto/crypto_user_base.c | 3 +++ 1 file changed, 3 insertions(+)