## Host environment - Operating system: * Linux - OS/kernel version: * Ubuntu 24.04-based Linux, kernel 6.17.0-19-generic - Architecture: * x86_64 - QEMU flavor: * qemu-system-x86_64 - QEMU version: * Base tree checked out from the official tag v11.0.0-rc4 * Base checkout commit (before local instrumentation): da6c4fe60fee The crashing binary was built from a locally modified tree based on that tag. The local instrumentation modified: - hw/nvme/ctrl.c - hw/nvme/nvme.h Note: both the tree VERSION file and the built binary reported 10.2.94, which appears inconsistent with the v11.0.0-rc4 tag name. - QEMU command line: ``` Launched via libvirt. Relevant redacted command-line details: - custom qemu-system-x86_64 binary from a locally instrumented build - machine: pc-q35-7.0 - NVMe system disk present - disk backend used aio=native, not io_uring - relevant disk line was equivalent to: -drive file=<redacted>,if=none,id=osdisk,format=raw,cache=none,aio=native,discard=unmap,detect-zeroes=unmap - relevant NVMe line was equivalent to: -device nvme,id=nvme0,serial=<redacted>,drive=osdisk,... ``` ## Emulated/Virtualized environment - Operating system: * Windows - OS/kernel version: * 22H2 19045.6332 - Architecture: * x86_64 ## Description of problem I reproduced a real crash in the NVMe DSM asynchronous path with a locally instrumented QEMU build on x86_64 Linux. The crashing binary was built from a locally modified tree based on the official tag v11.0.0-rc4 (base checkout commit observed before local instrumentation: da6c4fe60fee). The local instrumentation was added only to capture DSM callback/request/SQ lifetime state. The key runtime evidence is the following probe hit: DSM_PROBE hazard where=nvme_dsm_md_cb reason=req-dead iocb=0x561ae66b92b0 ret=0 saved_req=0x561ae80d8f30 saved_req_gen=60 saved_sq=0x561ae67f5480 saved_sq_gen=1 saved_ns=0x561ae6c2ddc0 saved_ctrl=0x561ae6c2b210 idx=62 nr=62 req_found=1 req_live=0 req_gen=60 sq_found=1 sq_live=0 sq_gen=1 This shows that nvme_dsm_md_cb() was entered after the associated request was already dead, and the associated submission queue was also already dead. In other words, a DSM metadata callback can arrive after request/SQ teardown and still follow saved request-associated state. This is a QEMU lifetime / robustness bug: regardless of what guest behavior triggers the timing window, QEMU should not end up crashing because a late DSM callback runs after the relevant request and queue are already dead. ## Steps to reproduce I do not currently have a minimal standalone reproducer. What I can say is: - the issue was reproduced with qemu-system-x86_64 on x86_64 Linux - the tested tree was based on the official v11.0.0-rc4 tag (base checkout commit: da6c4fe60fee) - the crashing binary was locally instrumented to record DSM callback/request/SQ lifetime state - the issue was observed under a real guest workload that exercises the NVMe DSM path - the tested NVMe system disk backend used aio=native ## Additional information This issue was first observed on QEMU 8.2.2. Relevant evidence collected from the instrumented build: 1. The decisive probe hit was: DSM_PROBE hazard where=nvme_dsm_md_cb reason=req-dead ... idx=62 nr=62 req_found=1 req_live=0 ... sq_found=1 sq_live=0 ... 2. This directly shows: - callback location: nvme_dsm_md_cb() - reason: req-dead - the associated request was already dead - the associated submission queue was already dead - the hit occurred at idx=62, nr=62 3. The crashing binary was built from a locally modified tree based on: - tag: v11.0.0-rc4 - base checkout commit: da6c4fe60fee 4. The local instrumentation modified: - hw/nvme/ctrl.c - hw/nvme/nvme.h 5. I suspect the same applies to `aio=io_uring`, because it crashed in `aio=io_uring` at the beginning (QEMU 8.2.2). I used targeted probe instrumentation instead of a core dump. ## Attachments I am attaching the following supporting material (redacted where needed): 1. Probe log excerpt showing the decisive hit: - `nvme_dsm_md_cb` - `reason=req-dead` - `idx=62` - `nr=62` - `req_live=0` - `sq_live=0` 2. A redacted command-line excerpt / libvirt log excerpt showing the relevant NVMe backend configuration used in the crashing run: - NVMe system disk backend - `aio=native` 3. A short source/build identity note describing: - base tag: `v11.0.0-rc4` - base checkout commit before local instrumentation: `da6c4fe60fee` - local DSM probe instrumentation applied afterward Attached file: [nvme-dsm-evidence-2026-04-16-111652.zip](/uploads/38cbc34e09bde05c8cea0b6e4f540024/nvme-dsm-evidence-2026-04-16-111652.zip)