spi: virtio: Use the per-transfer bits per word
Subsystems (4)
PATCH 1/1 spi: virtio: Use the per-transfer bits per word
virtio_spi_transfer_one() puts spi->bits_per_word into the request header, so a transfer that sets its own word size reaches the backend with the device default instead. The SPI core has already copied that default into xfer->bits_per_word when the transfer leaves it at zero, the same way it does for xfer->speed_hz, which this function already uses.
Per-transfer word sizes are ordinary SPI usage. mipi_dbi, for one, sends a 9-bit command and reads the reply as 8-bit data in the same message. With a 16-bit device default, a one-byte transfer asking for 8 bits goes out as a partial 16-bit word, which the backend may reject.
---
Reproduced with a local KUnit test, not part of this patch, that runs spi_sync() through this driver and the real split virtqueue against a software backend reading the request headers: 9 of 13 cases fail without the change, all 13 pass with it. Not tested against a real virtio-spi device or backend, so the framing on the wire was not observed.
drivers/spi/spi-virtio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-virtio.c +1 -1
@@ -168,7 +168,7 @@ static int virtio_spi_transfer_one(struct spi_controller *ctrl,/* Fill struct spi_transfer_head */ th->chip_select_id =spi_get_chipselect (spi,0 ); - th->bits_per_word = spi->bits_per_word; + th->bits_per_word = xfer->bits_per_word; th->cs_change = xfer->cs_change; th->tx_nbits = xfer->tx_nbits; th->rx_nbits = xfer->rx_nbits;
base-commit: cba2348ab114391f5b1a00fa65c5b739f13f0563
Signature · 1 line
2.43.0
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The driver unconditionally uses sg_init_one() on xfer->tx_buf and xfer->rx_buf, causing a crash or memory corruption if the SPI buffers are allocated via vmalloc. --
commit c48c32e667f00c40f450ecae1a3af2defbfd7bc2
Author: Hao-Qun Huang <[email protected]>
spi: virtio: Use the per-transfer bits per word
This commit updates the virtio SPI driver to correctly use the per-transfer bits_per_word value instead of the device default. This ensures that transfers with specific word sizes are not sent with partial words that the backend might reject.
drivers/spi/spi-virtio.c static int virtio_spi_transfer_one(struct spi_controller *ctrl, · line 174
Quoted 13 lines
drivers/spi/spi-virtio.c +1
-1@@ -168,7 +168,7 @@ static int virtio_spi_transfer_one(struct spi_controller *ctrl,/* Fill struct spi_transfer_head */ th->chip_select_id =spi_get_chipselect (spi,0 ); - th->bits_per_word = spi->bits_per_word; + th->bits_per_word = xfer->bits_per_word; th->cs_change = xfer->cs_change; th->tx_nbits = xfer->tx_nbits; th->rx_nbits = xfer->rx_nbits;
[Severity: High]
This is a pre-existing issue, but looking further down in virtio_spi_transfer_one(), the driver unconditionally passes the transfer buffers to sg_init_one():
if (spi_req->tx_buf) {
sg_init_one(&sg_out_payload, spi_req->tx_buf, xfer->len);
...
}
if (spi_req->rx_buf) {
sg_init_one(&sg_in_payload, spi_req->rx_buf, xfer->len);
...
}Does this cause memory corruption or a kernel crash if the SPI buffers are allocated via vmalloc?
The SPI core automatically bounce-buffers vmalloc memory into scatterlists, but only if the driver indicates DMA support by implementing the can_dma callback.
Since spi-virtio does not implement can_dma, __spi_map_msg() skips mapping and passes the virtual addresses directly to virtio_spi_transfer_one().
If a SPI client passes a vmalloc'd buffer, passing it to sg_init_one() will use virt_to_page() to compute an invalid struct page pointer.
When virtqueue_add_sgs() maps this scatterlist for DMA, would it calculate a bogus physical address based on this invalid page, causing the virtio device to overwrite or read from arbitrary physical memory, or triggering an IOMMU fault?
Would this mean any in-kernel client submitting a vmalloc'd SPI buffer could trigger this issue, leading to an unsafe DMA mapping that compromises kernel integrity?
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Mark Brown
maintainerQuoted 1 line · Hao-Qun Huang
spi: virtio: Use the per-transfer bits per word
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.3
Thanks!
[1/1] spi: virtio: Use the per-transfer bits per word
https://git.kernel.org/broonie/spi/c/095858324f06
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks,
Mark