linux-kernel - Re: [PATCH] tpm: tpm_tis_spi: Initialize ret variable in tpm_tis_spi_transfer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aVgAPP_bI1if2y6C@kernel.org>
Date: Fri, 2 Jan 2026 19:28:28 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Alper Ak <alperyasinak1@...il.com>
Cc: peterhuewe@....de, Jason Gunthorpe <jgg@...pe.ca>,
	Krishna Yarlagadda <kyarlagadda@...dia.com>,
	linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tpm: tpm_tis_spi: Initialize ret variable in
 tpm_tis_spi_transfer_half()

On Fri, Dec 26, 2025 at 02:35:04PM +0300, Alper Ak wrote:
> When len is 0, the while loop in tpm_tis_spi_transfer_half() is never
> entered and the function returns an uninitialized ret variable.
> 
> Initialize ret to 0 to correctly handle this case. This is consistent
> with tpm_tis_spi_transfer_full(), which already initializes ret to 0
> before the loop.
> 
> Fixes: a86a42ac2bd6 ("tpm_tis_spi: Add hardware wait polling")
> Signed-off-by: Alper Ak <alperyasinak1@...il.com>
> ---
>  drivers/char/tpm/tpm_tis_spi_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/tpm/tpm_tis_spi_main.c b/drivers/char/tpm/tpm_tis_spi_main.c
> index 61b42c83ced8..1b6d79662ca1 100644
> --- a/drivers/char/tpm/tpm_tis_spi_main.c
> +++ b/drivers/char/tpm/tpm_tis_spi_main.c
> @@ -85,7 +85,7 @@ static int tpm_tis_spi_transfer_half(struct tpm_tis_data *data,	u32 addr,
>  	struct spi_transfer spi_xfer[3];
>  	struct spi_message m;
>  	u8 transfer_len;
> -	int ret;
> +	int ret = 0;
>  
>  	while (len) {
>  		transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE);
> -- 
> 2.43.0
> 

OK, despite agreeing that 'ret' should be initialized I did not find a
call path where 'len' would end up being zero.

While acking the change in the sense that this function should be robust
enough to handle zero value for 'len', I'm just trying to figure out if
this is a regression from reproducability perspective, or just an 
improvement.

BR, Jarkko