Re: [PATCH v2 2/2] test: tpm: check malformed capability responses are rejected

Hi Shahriyar,

On 2026-07-24T10:34:14, shj <[email protected]> wrote:
> test: tpm: check malformed capability responses are rejected
>
> The length of a TPM reply comes from the device and cannot be trusted to
> be well-formed. Add tests for two malformed replies: one too short to hold
> the data it advertises, and one advertising more data than the request can
> hold. The sandbox TPM emulator gains two test-only properties that produce
> these replies, and two DM tests ask tpm2_get_capability() for them and
> check the call is rejected instead of parsing past the end of the reply or
> past the caller's buffer.
>
> Signed-off-by: Shahriyar Jalayeri <[email protected]>
> Acked-by: Miquel Raynal <[email protected]>
>
> drivers/tpm/tpm2_tis_sandbox.c | 27 +++++++++++++++++++++++++++
>  include/tpm-v2.h               | 10 ++++++++++
>  test/dm/tpm.c                  | 41 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 78 insertions(+)

> diff --git a/test/dm/tpm.c b/test/dm/tpm.c
> @@ -197,3 +198,43 @@ static int dm_test_tpm_autostart_reinit(struct unit_test_state *uts)
> +static int dm_test_tpm2_get_capability_long(struct unit_test_state *uts)

These two tests cover the tpm2_get_capability() paths nicely. I traced
them: the short reply lands at 10 bytes so it trips the
response_len < properties_off check, and the long reply advertises 51
bytes so it trips the caller-buffer bound. Both correctly exercise
patch 1.

But patch 1 also adds the TPM_RESPONSE_AUTH_LENGTH underflow guards in
tpm1_load_key2_oiap() and tpm1_get_pub_key_oiap(), which get no coverage
here. There is a v1 emulator (tpm_tis_sandbox.c), so a short-OIAP hook
along the same lines looks feasible. Please can you add a case for at
least one of those, or say why it is impractical?

Regards,
Simon