On Wednesday, 6 September 2023 Fiona Ebner wrote:
> If there is a pending DMA operation during ide_bus_reset(), the fact
> that the IDEState is already reset before the operation is canceled
> can be problematic. In particular, ide_dma_cb() might be called and
> then use the reset IDEState which
On Tuesday, 3 October 2023 John Snow wrote:
> Simon, can you confirm that Fiona's patches are appropriate for your
> reproducer? In the meantime I'll do my
> own audit for the problem as you described it (thank you very much for that)
> and see if there's anything else
> that needs to be
On Monday, 2 October 2023 John Snow wrote:
> Which reset pathway are you testing that causes the problem?
The test centres on a VM-initiated bus reset because a DMA write has stalled (I
deliberately discard the iSCSI response).
> I'm not fully clear on why checking for DRQ is legitimate here.
On Thursday, 28 September 2023 Fiona Ebner wrote:
> AFAICT, yes, because the DMA callback is invoked before resetting the
> state now. But not 100% sure if it can't be triggered in some other way,
> maybe Simon knows more? I don't have a reproducer for the CVE either,
> but the second patch
is still set in the DMA
callback (as it is otherwise cleared at the start of the bus
reset). If it is not, treat the transfer as ended.
This only appears to affect SATA controllers, plain IDE does not use
aio.
Fixes: CVE-2023-5088
Signed-off-by: Simon Rowe
Cc: Felipe Franciosi
---
hw/ide/core.c
in:
https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg03883.html
Simon Rowe (1):
hw/ide/core: terminate in-flight DMA on IDE bus reset
hw/ide/core.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--
2.22.3
On Wednesday, 14 June 2023 Simon Rowe wrote:
> We've also seen a handful of similar reports. Again, just the MBR sector
> overwritten by what looks to be guest data (e.g. log messages). The
> common thread with our incidents is again a SATA disk under the AHCI
> controller, we ha
On Thursday, 15 June 2023 Fiona Ebner wrote:
> which version/build of QEMU are you using? Can you correlate the issue
> with any block job or was the drive in use by the guest only?
I believe this has been seen on a range of releases so that includes QEMU 4.2
and 2.12. We do have custom patches
