[PATCH] KEYS: trusted: Fix blob allocation size in tpm2_key_decode()

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] keys: trusted: tpm2_key_decode() causes ZERO_SIZE_PTR dereference panic
--

commit 0b756ca20b74ac8e9fbfa99370ee0a0c61126972
Author: Stefano Garzarella <sgarzare at redhat.com>

KEYS: trusted: Fix blob allocation size in tpm2_key_decode()

This commit adjusts the allocation size for the TPM2 key blob in
tpm2_key_decode() to match the actual size of the decoded data, removing
an unnecessary 4-byte padding. The author notes that a separate commit,
114f00d738f1, fixes a boundary check in tpm2_load_cmd() that correctly
reports the decoded blob size.

> diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
> index 6340823f8b53c..ed88758c7e9bf 100644
> --- a/security/keys/trusted-keys/trusted_tpm2.c
> +++ b/security/keys/trusted-keys/trusted_tpm2.c
> @@ -116,7 +116,7 @@ static int tpm2_key_decode(struct trusted_key_payload *payload,
>  	if (ctx.priv_len + ctx.pub_len > MAX_BLOB_SIZE)
>  		return -EINVAL;
>  
> -	blob = kmalloc(ctx.priv_len + ctx.pub_len + 4, GFP_KERNEL);
> +	blob = kmalloc(ctx.priv_len + ctx.pub_len, GFP_KERNEL);
>  	if (!blob)
>  		return -ENOMEM;

[Severity: Critical]
Does this code handle the case where both lengths are zero?

If a payload contains empty strings for both privkey and pubkey,
asn1_ber_decoder() will succeed with ctx.priv_len and ctx.pub_len both
being 0 in tpm2_key_decode().

Because the padding has been removed, this results in:

    kmalloc(0, GFP_KERNEL)

which returns ZERO_SIZE_PTR (0x10). Since 0x10 is not NULL, the if (!blob)
check passes.

Later in security/keys/trusted-keys/trusted_tpm2.c:tpm2_load_cmd(), the
code unconditionally dereferences the newly allocated blob:

    private_len = get_unaligned_be16(blob);

The boundary check in tpm2_load_cmd() uses payload->blob_len (which is >= 15
for this ASN.1 sequence) instead of the decoded key length. Thus, the check
passes, dereferencing ZERO_SIZE_PTR and causing a kernel panic.

While the commit message mentions commit 114f00d738f1 as correctly reporting
the decoded blob size, that prerequisite commit is not present in this tree
or series. Applying this patch without its prerequisite introduces a
regression where this panic can occur.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923173506.41519-1-sgarzare@redhat.com?part=1