Re: [PATCH v2] KEYS: trusted: dcp: fix key_len validation and calc_blob_len() return type

Hi Fabrice,

> On 19.07.2026, at 18:41, Fabrice Derepas <[email protected]> w=
rote:
> =EF=BB=BFTwo correctness and type-hygiene issues exist in the DCP trusted k=
eys
> implementation.
>=20
> First, trusted_dcp_unseal() reads p->key_len from a user-supplied blob
> without checking if it exceeds MAX_KEY_SIZE.  If a crafted blob provides
> a payload_len larger than 128, the subsequent do_aead_crypto() call
> writes past the end of the p->key array into the adjacent p->blob
> buffer within the same struct trusted_key_payload -- the caller's own
> input, not unrelated kernel memory.  While not exploitable, this
> violates strict array bounds and triggers static analyzers.  Fix this by a=
dding a validation check against
> MIN_KEY_SIZE and MAX_KEY_SIZE immediately after reading the length,
> matching the checks already done in trusted_core.c.
>=20
> Second, calc_blob_len() calculates a sum in size_t that truncates to
> unsigned int on 64-bit platforms.  Because the DCP hardware is only
> present on 32-bit i.MX SoC platforms, size_t and unsigned int are
> functionally equivalent in production, making this truncation harmless in
> practice.  Nevertheless, updating the return type to size_t (and
> subsequently updating 'blen' in the seal/unseal paths) resolves
> type-narrowing warnings and improves overall code hygiene.
>=20
> Fixes: 2e8a0f40a39c ("KEYS: trusted: Introduce NXP DCP-backed trusted keys=
")
> Signed-off-by: Fabrice Derepas <[email protected]>
> ---
> Changes in v2:
>  - Reframed commit message as correctness/hardening fix (Richard, Jarkko)
>  - Changed bare return -EINVAL to goto out for consistency
>  - Added Fixes tag
>=20
> Compile-tested with arm-linux-gnueabihf-gcc on imx_v6_v7_defconfig
> with CONFIG_TRUSTED_KEYS_DCP=3Dy (W=3D1, zero warnings). No DCP hardware
> available for runtime testing.
>=20
> security/keys/trusted-keys/trusted_dcp.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>=20
> diff --git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trus=
ted-keys/trusted_dcp.c
> index 7b6eb655d..c078adebe 100644
> --- a/security/keys/trusted-keys/trusted_dcp.c
> +++ b/security/keys/trusted-keys/trusted_dcp.c
> @@ -69,7 +69,7 @@ static bool skip_zk_test;
> module_param_named(dcp_skip_zk_test, skip_zk_test, bool, 0);
> MODULE_PARM_DESC(dcp_skip_zk_test, "Don't test whether device keys are zer=
o'ed");
>=20
> -static unsigned int calc_blob_len(unsigned int payload_len)
> +static size_t calc_blob_len(unsigned int payload_len)
> {
>    return sizeof(struct dcp_blob_fmt) + payload_len + DCP_BLOB_AUTHLEN;
> }
> @@ -200,7 +200,8 @@ static int encrypt_blob_key(u8 *plain_key, u8 *encrypt=
ed_key)
> static int trusted_dcp_seal(struct trusted_key_payload *p, char *datablob)=

> {
>    struct dcp_blob_fmt *b =3D (struct dcp_blob_fmt *)p->blob;
> -    int blen, ret;
> +    size_t blen;
> +    int ret;
>    u8 *plain_blob_key;
>=20
>    blen =3D calc_blob_len(p->key_len);
> @@ -242,7 +243,8 @@ static int trusted_dcp_seal(struct trusted_key_payload=
 *p, char *datablob)
> static int trusted_dcp_unseal(struct trusted_key_payload *p, char *datablo=
b)
> {
>    struct dcp_blob_fmt *b =3D (struct dcp_blob_fmt *)p->blob;
> -    int blen, ret;
> +    size_t blen;
> +    int ret;
>    u8 *plain_blob_key =3D NULL;
>=20
>    if (b->fmt_version !=3D DCP_BLOB_VERSION) {
> @@ -253,9 +255,14 @@ static int trusted_dcp_unseal(struct trusted_key_payl=
oad *p, char *datablob)
>    }
>=20
>    p->key_len =3D le32_to_cpu(b->payload_len);
> +    if (p->key_len < MIN_KEY_SIZE || p->key_len > MAX_KEY_SIZE) {
> +        ret =3D -EINVAL;
> +        goto out;
> +    }
> +
>    blen =3D calc_blob_len(p->key_len);
>    if (blen !=3D p->blob_len) {
> -        pr_err("DCP blob has bad length: %i !=3D %i\n", blen,
> +        pr_err("DCP blob has bad length: %zu !=3D %u\n", blen,
>               p->blob_len);
>        ret =3D -EINVAL;
>        goto out;
>=20
> base-commit: 6d41c11ef3044788902a05e292cd7f0a9c7a8157
> --
> 2.53.0
>=20

LGTM and thanks for the fix!

Reviewed-by: David Gstir <[email protected]>

- David=