From: Richard Weinberger <richard@sigma-star.at>
To: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org,
upstream@sigma-star.at
Cc: Fabrice Derepas <fabrice.derepas@canonical.com>,
david@sigma-star.at, upstream+dcp@sigma-star.at,
jarkko@kernel.org, zohar@linux.ibm.com, dhowells@redhat.com,
Fabrice Derepas <fabrice.derepas@canonical.com>
Subject: Re: [PATCH v2] KEYS: trusted: dcp: fix key_len validation and calc_blob_len() return type
Date: Sun, 19 Jul 2026 18:53:14 +0200 [thread overview]
Message-ID: <3761945.KsABhTYbVQ@nailgun> (raw)
In-Reply-To: <20260719163939.3624767-1-fabrice.derepas@canonical.com>
On Sonntag, 19. Juli 2026 18:39 'Fabrice Derepas' via upstream wrote:
> Two correctness and type-hygiene issues exist in the DCP trusted keys
> implementation.
>
> 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 adding 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.
>
> 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.
>
> Fixes: 2e8a0f40a39c ("KEYS: trusted: Introduce NXP DCP-backed trusted keys")
> Signed-off-by: Fabrice Derepas <fabrice.derepas@canonical.com>
Reviewed-by: Richard Weinberger <richard@nod.at>
Thanks,
//richard
--
sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y
next prev parent reply other threads:[~2026-07-19 16:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 20:28 [PATCH] KEYS: trusted: dcp: fix key_len validation and calc_blob_len() return type Fabrice Derepas
2026-07-18 21:12 ` Richard Weinberger
2026-07-18 22:13 ` Jarkko Sakkinen
2026-07-18 22:16 ` Jarkko Sakkinen
2026-07-19 13:44 ` Fabrice Derepas
2026-07-19 16:39 ` [PATCH v2] " Fabrice Derepas
2026-07-19 16:53 ` Richard Weinberger [this message]
2026-07-20 10:34 ` David Gstir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3761945.KsABhTYbVQ@nailgun \
--to=richard@sigma-star.at \
--cc=david@sigma-star.at \
--cc=dhowells@redhat.com \
--cc=fabrice.derepas@canonical.com \
--cc=jarkko@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=upstream+dcp@sigma-star.at \
--cc=upstream@sigma-star.at \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.