Re: [PATCH v6 27/40] scsi: stex: use 16-bits defined sense codes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Kernel panic upon DMA mapping failure due to BUG_ON(nseg < 0).
--

commit d15faa7735c6e8a30c881eeb0c04ddfab88366ab
Author: Damien Le Moal <dlemoal@kernel.org>
scsi: stex: use 16-bits defined sense codes

This commit refactors the stex driver to use scsi_set_sense() and replaces
hard-coded additional sense codes with enum values. This improves code clarity
and ensures the sense codes are self-documented.

> diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
> index 6aeeb338633df..056ff0eb5455c 100644
> --- a/drivers/scsi/stex.c
> +++ b/drivers/scsi/stex.c
[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in the DMA
mapping error handling while reviewing this file.

In drivers/scsi/stex.c:stex_map_sg():

	nseg = scsi_dma_map(cmd);
	BUG_ON(nseg < 0);

And similarly in drivers/scsi/stex.c:stex_ss_map_sg():

	nseg = scsi_dma_map(cmd);
	BUG_ON(nseg < 0);

Can this crash the kernel under memory pressure? 

If scsi_dma_map() fails (for example, if the SWIOTLB is full or IOMMU space
is exhausted), it returns -ENOMEM. The driver then immediately triggers the
BUG_ON(nseg < 0) statement, crashing the system instead of gracefully handling
the error. Since this is reachable via normal I/O paths, could unprivileged
userspace trigger memory pressure to induce this failure and cause a local
denial of service?

Would it make sense to update these functions to handle the failure and
return SCSI_MLQUEUE_HOST_BUSY, allowing the SCSI midlayer to retry?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908090308.1085097-1-dlemoal@kernel.org?part=27