On Samstag, 18. Juli 2026 22:28 'Fabrice Derepas' via upstream wrote:
> Two defects in trusted_dcp_unseal() combine to allow a heap
> out-of-bounds write in kernel context.
>
> The primary defect is a missing upper-bound check:
> trusted_dcp_unseal() reads p->key_len from an attacker-supplied blob
> with no validation that it is at most MAX_KEY_SIZE (128). It then
> passes p->key_len + DCP_BLOB_AUTHLEN to do_aead_crypto() as the
> operation length. Because p->key is only MAX_KEY_SIZE + 1 = 129
> bytes, any payload_len above 128 in the blob overruns p->key. On
> implementations where AES-128-GCM decryption writes plaintext before
> verifying the authentication tag, up to 330 bytes of out-of-bounds
> heap overwrite can occur before -EBADMSG is returned.
Hmm, but this will only overflow p->blob[], which is the attacker input.
p->blob[] is at least 512 bytes long.
So an attacker is only able to overwrite it's own provided input?
> The secondary defect is an integer overflow in calc_blob_len(), which
> computes its sum in size_t but returns unsigned int, truncating the
> result on 64-bit platforms. This allows a crafted blob with
> payload_len near UINT_MAX to bypass the sanity check
> (blen != p->blob_len). Due to a second wrap in the expression
> p->key_len + DCP_BLOB_AUTHLEN (computed in unsigned int at the call
> site), the len value that reaches do_aead_crypto() via this path is
> at most 15 bytes and does not directly amplify the OOB write, but
> the integrity check bypass must be fixed.
Since the DCP engine is only found on tiny 32-bits NXP i.MX systems,
I don't consider this a real issue.
> Fix the primary OOB by validating p->key_len against MIN_KEY_SIZE
> and MAX_KEY_SIZE immediately after reading it from the blob, matching
> the validation already performed in trusted_core.c on the Opt_new
> path. Fix the overflow by changing the return type of calc_blob_len()
> to size_t; update the two blen declarations from int to size_t to
> avoid narrowing-conversion warnings, and update the pr_err format
> specifier for blen accordingly.
>
> The seal path is not affected: p->key_len is validated by
> trusted_core.c before trusted_dcp_seal() is called, and the
> blen > MAX_BLOB_SIZE guard provides defence in depth there.
>
> Exploitation requires high privileges. The unseal path is reached
> via add_key("trusted", ..., KEY_SPEC_*) with the Opt_load command,
> which requires write permission to a keyring that accepts trusted
> keys -- in practice CAP_SYS_ADMIN. Additionally,
> CONFIG_TRUSTED_KEYS_DCP must be enabled. The attacker must also supply
> a crafted sealed blob, which in the typical dm-crypt use case means
> either physical access to modify on-disk key material or a prior
> compromise of a privileged process that writes the blob.
While I welcome the proposed changes as they make the code more clear
and will other tools happy, I don't think it's a security issue.
So the commit message needs rewording.
Thanks,
//richard
--
sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y
