Re: [PATCH] tpm-buf: memory-safe allocations

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2026-05-22 at 04:35 +0300, Jarkko Sakkinen wrote:
> Decouple kzalloc from buffer creation, so that a managed allocation
> can be
> used:
> 
> 	struct tpm_buf *buf __free(kfree) buf = kzalloc(TPM_BUFSIZE,
> 						GFP_KERNEL);
> 	if (!buf)
> 		return -ENOMEM;
> 
> 	tpm_buf_init(buf, TPM_BUFSIZE);
> 
> Alternatively, stack allocations are also possible:
> 
> 	u8 buf_data[512];
> 	struct tpm_buf *buf = (struct tpm_buf *)buf_data;
> 	tpm_buf_init(buf, sizeof(buf_data));

This isn't really a good idea from a security point of view.  Remember
the buffer has to be big enough for both the sent and the received
data.  Today we simply set TPM_BUFSIZE to the maximum amount a TPM
requires and all the send and receives just work.  If we let callers
set this size, we're asking for them to get it wrong (or at least
forget about the receive part) and for us to get a DMA overrun from the
TPM ... which might be potentially exploitable depending on how it
occurs (think of an unseal of user chosen data overrunning).

I get the desire to support some of the newer chunked commands, but
since none of them is yet present in the kernel, why not introduce an
API that works only for them to avoid the risk of a security cockup in
existing code?

Regards,

James