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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox