Re: [PATCH v3 2/2] scsi: mpt3sas: add hwmon support

[Louis Sautier <sautier.louis@gmail.com>]

On Sun, 24 May 2026 22:49:27 +0000, sashiko-bot@kernel.org wrote:
> [Severity: High]
> Could these uninitialized stack variables lead to memory corruption or
> information leaks?
> 
> If the firmware completes the config request without a reply frame payload,
> the underlying _config_request() returns 0 but skips populating mpi_reply.
> The subsequent config read request relies on mpi_reply.Header.PageLength
> and mpi_reply.ExtPageLength to compute the DMA memory allocation size.
> Using uninitialized stack garbage for the size might lead to unpredictable
> dma_alloc_coherent() behavior.

In _hwmon_read, I declare mpi_reply the same way every other
mpt3sas_config_get_*_pgN() accessor in mpt3sas_config.c does.

> Additionally, if page is not fully initialized by the hardware response,
> stack garbage might be returned to userspace via _hwmon_to_mdegc().
> Should these structs be zero-initialized?

The page argument is zeroed by _config_request() before the read, at
mpt3sas_config.c:344 (memset(config_page, 0, config_page_sz)).
The bot's own review log notes this: "the code *does* explicitly set
`config_page` to zero."

> [Severity: High]
> This is a pre-existing issue, but does calling mpt3sas_config_get_iounit_pg7()
> expose a data race with the config_cmds state machine?

This is indeed pre-existing in the driver and outside the scope of my patch.

> [Severity: High]
> Similarly here, can the uninitialized mpi_reply and page variables cause
> the same issues described above during the config page request?

Same answer as for _hwmon_read above: mpi_reply matches the existing
mpt3sas convention.