## Host environment Operating system: OS/kernel version: Architecture: QEMU flavor: QEMU version: QEMU command line: **Severity**: Medium ### Advisory Details **Title**: Guest-triggerable NULL pointer dereference in QEMU IDE SRST DMA cancellation path **Description**: A guest running on the supported `pc` machine type can crash the host `qemu-system-x86_64` process by starting an IDE DMA discard on slave unit 1 while master unit 0 is empty, then issuing a guest-visible software reset. The SRST path cancels DMA against the wrong slot and reaches `blk_drain(NULL)`, terminating the QEMU process. ### Summary QEMU's IDE software-reset path uses bus-wide DMA state together with per-slot block backend state without validating that the currently reset slot actually owns the pending DMA backend. An unprivileged guest can turn that mismatch into a reliable denial of service against the host QEMU process when the IDE topology is `unit 0 = empty`, `unit 1 = disk`, and a DMA discard is still pending at the moment `IDE_CTRL_RESET` is written. ### Details The root cause lives in `hw/ide/core.c`. `ide_cancel_dma_sync()` only checks whether the IDE bus still has a pending DMA callback: ```c if (s->bus->dma->aiocb) { trace_ide_cancel_dma_sync_remaining(); blk_drain(s->blk); assert(s->bus->dma->aiocb == NULL); } ``` That logic is safe only if `s` is the slot that actually owns the live DMA backend. The SRST path does not maintain that invariant. `ide_ctrl_write()` schedules `ide_bus_perform_srst()` when the guest sets `IDE_CTRL_RESET`, and that helper always walks the two IDE slots in fixed master-then-slave order: ```c static void ide_perform_srst(IDEState *s) { s->status |= BUSY_STAT; ide_transfer_halt(s); ide_cancel_dma_sync(s); ide_reset(s); cmd_exec_dev_diagnostic(s, WIN_DIAGNOSE); } static void ide_bus_perform_srst(void *opaque) { IDEBus *bus = opaque; IDEState *s; int i; for (i = 0; i < 2; i++) { s = &bus->ifs[i]; ide_perform_srst(s); } } ``` If the guest arranges the bus so that: - `ide.0` unit 0 has no disk (`s->blk == NULL`), - `ide.0` unit 1 has the active DMA-backed disk, - and a discard/DSM DMA request on unit 1 is still pending, then the SRST walk reaches the empty master first. At that moment `s->bus->dma->aiocb` is still non-NULL because the slave's DMA has not completed, but the current slot's `s->blk` is NULL. `ide_cancel_dma_sync()` then calls `blk_drain(NULL)` and the process dies with `SIGSEGV`. The PoC in the exp folder demonstrates this through the real public interface used by a guest: a multiboot guest payload writes PCI IDE configuration space, IDE task-file ports, and BMDMA registers, then asserts `IDE_CTRL_RESET` while DMA is active. The control removes only the pending-DMA precondition and survives the reset path, which isolates the bug to the mismatched DMA/slot state rather than to the reset itself. ### PoC #### Prerequisites - A host capable of building `qemu-system-x86_64` from this repository. - `gcc` with 32-bit output support for the multiboot guest payload used by `build_guest.sh`. - The PoC expects the supported `pc` machine type with an empty IDE master (`unit 0`) and a populated IDE slave (`unit 1`). - The verification harness uses a `blkdebug` wrapper to keep the discard DMA pending long enough to reproduce the vulnerable race window consistently. #### Reproduction Steps 1. Download the build helper from: [build_qemu_clean.sh](https://gist.github.com/YLChen-007/946ef28e7a178b15208c6ef7c4b08d95) 2. Download the guest builder from: [build_guest.sh](https://gist.github.com/YLChen-007/568512b4a6a880becd18e11b794ceab4) 3. Download the guest payload sources from: - [guest_srst_empty_master.c](https://gist.github.com/YLChen-007/2cc95d7d9c2b486ac4c02368e1258183) - [boot.S](https://gist.github.com/YLChen-007/3cdb46a1def16a656f9d41fe0af3de0f) - [kernel.ld](https://gist.github.com/YLChen-007/798538f62e5523f3cf25a896a6db9f8d) 4. Download the runtime harness from: - [verification_test.py](https://gist.github.com/YLChen-007/11ac721bc4046b43f5f725443f482d23) - [control-no-pending-dma.py](https://gist.github.com/YLChen-007/1d31d5461ea73030d77dfb7f549c382c) 5. Place those files in the same directory and build the target plus guest payload: ```bash ./build_qemu_clean.sh ./build_guest.sh ``` 6. Run the exploit: ```bash python3 verification_test.py \ --qemu-bin ./build-origin-master/qemu-system-x86_64 \ --guest-kernel ./guest-build/guest_srst_empty_master.bin ``` 7. Confirm the crash: - output contains `[DEFECT CONFIRMED]` - output contains `Exit: process died from SIGSEGV` - output contains `Guest debug trace: 'SA'` 8. Run the matched control: ```bash python3 control-no-pending-dma.py \ --qemu-bin ./build-origin-master/qemu-system-x86_64 ``` 9. Confirm the control survives: - output contains `[CONTROL PASSED]` - output contains `Guest debug trace: 'SNR'` Auxiliary and legacy harness files from the exp folder were also uploaded separately for completeness: - [verification_test_CVE-2020-25743.py](https://gist.github.com/YLChen-007/101f4dea641e620728f67533086de621) - [control-populated-master.py](https://gist.github.com/YLChen-007/4e9c99c2e7de7e6ea0ec9c6ca3c2a241) - [build_qemu.sh](https://gist.github.com/YLChen-007/0fe9cbcedd2e47a60aff67a0fafea72f) ### Log of Evidence ```text $ python3 verification_test.py --qemu-bin ./build-origin-master/qemu-system-x86_64 --guest-kernel ./guest-build/guest_srst_empty_master.bin Verification mode: End-to-End Scenario: srst-empty-master Flow: [Guest multiboot kernel] -> [guest PCI/BMDMA register writes on IDE unit 1] -> [pending bus-wide DMA aiocb] -> [guest software reset on the same IDE bus] -> [QEMU reset loop enters master slot first] -> [ide_cancel_dma_sync()/blk_drain(NULL)] [DEFECT CONFIRMED] QEMU crashed after the guest-visible reset trigger (process died from SIGSEGV). Exit: process died from SIGSEGV Guest debug trace: 'SA' ``` ```text $ python3 control-no-pending-dma.py --qemu-bin ./build-origin-master/qemu-system-x86_64 Verification mode: End-to-End Scenario: control-no-pending-dma Flow: [Guest multiboot kernel] -> [guest PCI/BMDMA register writes on IDE unit 1] -> [pending bus-wide DMA aiocb] -> [guest software reset on the same IDE bus] -> [QEMU reset loop enters master slot first] -> [ide_cancel_dma_sync()/blk_drain(NULL)] [CONTROL PASSED] Control survived the reset path and reached the post-reset guest marker. Exit: process exited with status 67 Guest debug trace: 'SNR' QEMU stderr: qemu-system-x86_64: terminating on signal 15 from pid 1146459 (python3) ``` ### Impact This is a guest-triggerable denial of service in the host QEMU process. A tenant or user who can execute code inside a guest with this IDE topology can terminate the `qemu-system-x86_64` process backing that VM. The immediate effect is loss of availability for the VM, interruption of in-flight workloads, and possible guest-visible disk consistency fallout if the crash lands during active I/O. The issue does not itself grant host code execution or cross-VM data access, but it is a real guest-to-host isolation failure on an in-scope device boundary. ### Affected products - **Ecosystem**: GitHub - **Package name**: qemu/qemu - **Affected versions**: <= 11.0.2 - **Patched versions**: <None> ### Severity - **Severity**: Medium - **Vector string**: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H ### Weaknesses - **CWE**: CWE-476: NULL Pointer Dereference ### Occurrences | Permalink | Description | | :--- | :--- | | [https://github.com/qemu/qemu/blob/e545d8bb9d63e9dd61542b88463183314cff9482/hw/ide/core.c#L745-L748](https://github.com/qemu/qemu/blob/e545d8bb9d63e9dd61542b88463183314cff9482/hw/ide/core.c#L745-L748) | `ide_cancel_dma_sync()` drains `s->blk` whenever the bus-wide DMA state is still pending, without checking whether the current slot has a non-NULL backend. | | [https://github.com/qemu/qemu/blob/e545d8bb9d63e9dd61542b88463183314cff9482/hw/ide/core.c#L2315-L2340](https://github.com/qemu/qemu/blob/e545d8bb9d63e9dd61542b88463183314cff9482/hw/ide/core.c#L2315-L2340) | The SRST helper unconditionally calls `ide_cancel_dma_sync(s)` for each slot and then iterates the bus in fixed master-then-slave order, creating the empty-master/pending-slave-DMA mismatch. | | [https://github.com/qemu/qemu/blob/e545d8bb9d63e9dd61542b88463183314cff9482/hw/ide/core.c#L2356-L2362](https://github.com/qemu/qemu/blob/e545d8bb9d63e9dd61542b88463183314cff9482/hw/ide/core.c#L2356-L2362) | A guest write of `IDE_CTRL_RESET` schedules `ide_bus_perform_srst()`, making the vulnerable path directly reachable from guest-visible register I/O. |