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: `<CAJUmCq5D60wwskW-aDR=23_d8dHxSrrg2D7ngBCic90wwCvBuw@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 DMG image handling path used by qemu-img. 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 DMG image can trigger a heap out-of-bounds read in the actual chunk data read path during image conversion. If you confirm that this falls within QEMU's security policy, please assign a CVE and handle it under coordinated disclosure. Affected area: qemu-img DMG chunk read path block/dmg.c Affected version tested: qemu-11.0.0-rc4 Impact summary: A crafted DMG image can create an inconsistency between lengths[] and sectorcounts[] for a UDRW chunk, causing QEMU to allocate an uncompressed chunk buffer based on the smaller length but later read data out of that buffer using the larger sector count. In my testing this is reproducible as an ASan-detected heap-buffer-overflow read. Root cause summary: Two different size notions are used for the same chunk: 1. During initialization, update_max_chunk_size() derives the required uncompressed buffer size from lengths[chunk]. 2. During actual reads, dmg_co_preadv() derives the readable logical range from sectorcounts[chunk]. If a crafted DMG image makes: sectorcounts[chunk] > DIV_ROUND_UP(lengths[chunk], 512) then QEMU allocates and fills a smaller uncompressed buffer but later reads from it as if a larger logical sector range were available. Code locations involved: - block/dmg.c: update_max_chunk_size() - block/dmg.c: dmg_open() - block/dmg.c: dmg_read_chunk() - block/dmg.c: dmg_co_preadv() Reproducer: I attached a malicious DMG sample and a simple reproducer script. The reproducer runs a command similar to: UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=0 \ ./qemu-img convert -f dmg -O raw crafted.dmg /tmp/out.raw Observed result: After allowing execution to continue past an earlier unrelated unaligned-access warning, AddressSanitizer reports a heap-buffer-overflow read in the data-copy path reached from dmg_co_preadv(). Example ASan symptom: ERROR: AddressSanitizer: heap-buffer-overflow READ of size 512 SUMMARY: AddressSanitizer: heap-buffer-overflow ... in iov_from_buf_full Attack scenario: A user or automated pipeline that processes an untrusted DMG image with qemu-img can be made to trigger out-of-bounds memory access and denial of service. Disclosure status: This issue is not public to the best of my knowledge. Suggested fix direction: QEMU should enforce consistency between lengths[] and sectorcounts[] for UDRW chunks before using either value in allocation or read-bound calculations. Attachments: - https://drive.google.com/file/d/1n4mvGgng4d32zUtpo7Q3bOsCpjFROkhu/view?usp=sharing - repro.sh - crash_1774548089_agent1.img - repro.log Please let me know if you would like me to provide: - the full ASan/UBSan logs, - a minimized image, - or a proposed patch.