Re: [PATCH v4 01/10] crypto: pkcs7: add flag for validated trust on a signed info block

[sashiko-bot@kernel.org]

Sashiko AI review found 2 potential issue(s):
- [Critical] Stateful Trust Validation / Blacklist Trust Confusion (Authentication Bypass)
- [Low] API Export Constraint Mismatch
--

commit 4ed8f1fbacef58172cae707b05aaa2b29ba6f7c1
Author: James Bottomley <James.Bottomley@HansenPartnership.com>

crypto: pkcs7: add flag for validated trust on a signed info block

This patch adds a flag to struct pkcs7_signed_info to indicate if a
signer has passed trust validation. It also exports
verify_pkcs7_message_sig() so modules can access the trusted object.

> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index e0761436ec7f4..9bda49295bd02 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -380,6 +380,7 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
>  	pr_devel("<==%s() = %d\n", __func__, ret);
>  	return ret;
>  }
> +EXPORT_SYMBOL(verify_pkcs7_message_sig);

This isn't a bug, but should this be exported using EXPORT_SYMBOL_GPL to
match the rest of the PKCS#7 subsystem?

Other cryptographic verification and parsing functions like
verify_pkcs7_signature(), pkcs7_parse_message(), and pkcs7_verify()
are strictly exported as EXPORT_SYMBOL_GPL.

[ ... ]

> diff --git a/crypto/asymmetric_keys/pkcs7_trust.c b/crypto/asymmetric_keys/pkcs7_trust.c
> index 9a87c34ed1733..78ebfb6373b61 100644
> --- a/crypto/asymmetric_keys/pkcs7_trust.c
> +++ b/crypto/asymmetric_keys/pkcs7_trust.c
> @@ -127,6 +127,7 @@ static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
>  		for (p = sinfo->signer; p != x509; p = p->signer)
>  			p->verified = true;
>  	}
> +	sinfo->verified = true;
>  	kleave(" = 0");
>  	return 0;
>  }

Is this verified flag persistent across multiple trust validation passes?

When verify_pkcs7_message_sig() checks a message against the blacklist keyring
first:

verify_pkcs7_message_sig()
  is_key_on_revocation_list()
    pkcs7_validate_trust(pkcs7, blacklist_keyring)
      pkcs7_validate_trust_one()
        sinfo->verified = true;

If a signature matches a blacklisted key, sinfo->verified is set to true.

If the validation later aborts because a different signature fails to verify
and returns -EKEYREJECTED, the blacklist check will abort and the caller
might interpret the result as not blacklisted.

When the same message is subsequently validated against the trusted keyring,
another valid signature could cause the overall trust check to succeed.

Could this allow a caller to mistakenly extract attributes from the first
signer block where verified is true, which in this scenario would be the
blacklisted signature?

Would it be better to clear the verified flags before validation, or keep
them scoped to the specific keyring being checked?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260416173500.176716-1-bboscaccy@linux.microsoft.com?part=1