spi: cadence-xspi: two memory-safety fixes in the slave-DMA paths

Weibin Liu <liuwb@xiaopeng.com> says:

While reviewing the slave-DMA handling of the Cadence XSPI driver I
found two ways in which memory the SPI core handed to the driver can be
overrun:

  1/2 both SDMA handlers copy the byte count reported by SDMA_SIZE_REG
      without checking it against the requested transfer length; a
      device reporting more bytes than were programmed makes the
      handlers walk past the end of the transfer buffers

  2/2 the Marvell b0 transfer path points the SDMA buffers at a
      10-byte stack scratch area for transfers without TX data;
      transfers longer than that overflow it in both directions and
      clock out uninitialized stack bytes to the attached device

The two patches are independent of each other and each carries its own
Fixes: tag, so they can be queued separately.

Tested on x86_64: with both patches applied the driver builds, loads
and unloads cleanly; no xSPI controller is available in this
environment to exercise the slave-DMA paths on hardware. Details are
in the notes of the individual patches.

Link: https://patch.msgid.link/20260929081146.41041-1-liuwb@xiaopeng.com

0 files changed, 0 insertions, 0 deletions