Re: [PATCH] ata: pata_atiixp trivial fix

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] ata: out-of-bounds read in atiixp_set_dmamode() via libata.force
--

commit 6cef46d304d8efc0941f3fea452622301931fdb7
Author: Ioannis Barkas <jnyb.de@gmail.com>

ata: pata_atiixp trivial fix

Reduce mwdma_timings to match its members.

> diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
> index 4c612f9543f6c..50f2c9077af05 100644
> --- a/drivers/ata/pata_atiixp.c
> +++ b/drivers/ata/pata_atiixp.c
> @@ -149,7 +149,7 @@ static void atiixp_set_piomode(struct ata_port *ap, struct ata_device *adev)
>  
>  static void atiixp_set_dmamode(struct ata_port *ap, struct ata_device *adev)
>  {
> -	static const u8 mwdma_timings[5] = { 0x77, 0x21, 0x20 };
> +	static const u8 mwdma_timings[3] = { 0x77, 0x21, 0x20 };

[Severity: Medium]
Does this code introduce an out-of-bounds read when libata.force is used?

If a user specifies libata.force=mwdma3 or mwdma4, ata_force_xfermask() can
override the hardware port limits and force adev->dma_mode to XFER_MW_DMA_3
or XFER_MW_DMA_4.

When atiixp_set_dmamode() is subsequently called, dma -= XFER_MW_DMA_0
evaluates to 3 or 4:

		dma -= XFER_MW_DMA_0;
		...
		mwdma_timing_data |= (mwdma_timings[dma] << timing_shift);

This would cause an out-of-bounds memory read since mwdma_timings was reduced
to 3 elements. The previous 5-element array provided safe zero-padding for
these forced modes.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013043106.77115-1-jnyb.de@gmail.com?part=1