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
