Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `boy juju <agx1657748706@gmail.com>` * Date: `18 May, 2026` * Message ID: `<CAJUmCq575W6beLXzYDA4jzPZNU=d4J3NN1eoVStqYSc7mfrocg@mail.gmail.com>` **NOTE:** the original reporter can not be copied on this issue so cannot view this ticket while it remains marked confidential. If further information is needed about the disclosure, contact the reporter directly. ---- I would like to report a potential security issue in QEMU's emulated NVMe controller. Automated discovery declaration: This issue was discovered with fuzzing assistance and then manually triaged and validated. I believe this issue may be security-relevant because a malicious guest can trigger a heap out-of-bounds write in the host QEMU process by issuing a crafted NVMe COPY command to the emulated controller. If you confirm that this falls within QEMU's security policy, please assign a CVE and handle it under coordinated disclosure. Affected area: hw/nvme COPY command handling corresponding-PI metadata generation path Affected version tested: qemu-11.0.0-rc4 Impact summary: A guest can issue a cross-namespace format-2 COPY where the source namespace has no metadata but the destination namespace uses PI metadata, together with PRACT, and cause the host QEMU process to write beyond the end of a heap-allocated bounce buffer. In my testing this is reproducible as an ASan-detected heap-buffer-overflow write. Root cause summary: The COPY implementation accepts a valid corresponding-PI source/destination format combination, but allocates the bounce buffer based only on the source namespace layout. Later, completion handling reinterprets the same buffer according to the destination namespace layout and writes destination metadata / DIF data beyond the originally allocated range. The critical mismatch is: 1. allocation uses source namespace data size, 2. completion uses destination namespace metadata size, and 3. the generated PI data is written past the end of the source-sized buffer. Code locations involved: - hw/nvme/ctrl.c: nvme_do_copy() - hw/nvme/ctrl.c: nvme_copy_in_completed_cb() - hw/nvme/ctrl.c: nvme_dif_pract_generate_dif*() Reproducer: I attached a guest-side reproducer and a wrapper script that boots a minimal guest and issues the crafted NVMe COPY command from inside the guest. Observed result: AddressSanitizer reports a heap-buffer-overflow write in the DIF generation path after the guest issues the COPY request. Example ASan symptom: ERROR: AddressSanitizer: heap-buffer-overflow in nvme_dif_pract_generate_dif_crc16(...) in nvme_copy_in_completed_cb(...) Attack scenario: A malicious guest with access to the emulated NVMe device can issue crafted NVMe commands that cause memory corruption in the host QEMU process. Disclosure status: This issue is not public to the best of my knowledge. Suggested fix direction: The COPY bounce-buffer allocation should account for the full source-data plus destination-metadata requirements of the operation, rather than using only the source namespace layout. Attachments: - https://drive.google.com/file/d/1X9TbzwU9-cZdkIGOhux9FdAHgcY_lRO3/view?usp=sharing - repro.sh - nvme_copy_corresp_pi_guest.py - nvme_copy_corresp_pi_guest.c - repro.log - result.json - qemu.stderr Please let me know if you would like me to provide: - the full ASan log, - a minimized guest-side test case, - or a proposed patch.