Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `"1668581766" <1668581766@qq.com>` * Date: `31 May, 2026` * Message ID: `<tencent_31A1A5A0006643CBCDF1B94F8683D7B44A09@qq.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 am reporting a potential security issue in the SM501 device model. Automated-tool disclosure: AI/LLM assistance was used during code review and report preparation. The finding and reproducer were manually triaged and validated locally against an upstream QEMU build. ## Reporter / acknowledgement: Please acknowledge: Yannick Wang ## Summary: A guest with access to the SM501 2D engine MMIO registers can program an RTL 2D operation with width/height larger than the destination/source coordinates. QEMU subtracts `width - 1` and `height - 1` from unsigned coordinates before validating bounds. This underflows the coordinates and allows invalid offsets to reach the fallback BitBlt / Rectangle Fill paths. ## Observed impact: I can reliably trigger a QEMU process abort under ASAN. A non-ASAN build on my macOS host stopped responding to qtest and consumed 100% CPU. The affected paths include out-of-bounds read/write conditions in the SM501 local memory copy/fill logic. I have not proven host code execution. ## Tested version: QEMU master commit: 81cc5f39aa3042e9c0b2ea772b42a2c8b1488e76 VERSION: 11.0.50 ## Host / guest: Host: macOS arm64 Target: sh4-softmmu Machine: r2d ## Affected code: hw/display/sm501.c ## Root cause: In `sm501_2d_operation()`: if (rtl) { dst_x -= width - 1; dst_y -= height - 1; } and in the BitBlt source path: if (rtl) { src_x -= width - 1; src_y -= height - 1; } `dst_x`, `dst_y`, `src_x`, and `src_y` are unsigned. If, for example, `dst_x = 0` and `width = 8191`, the subtraction underflows before the bounds check. The later bounds calculation can wrap and fail to reject the invalid operation. ## QEMU command line: qemu-system-sh4 -M r2d -display none -audio none -serial none \ -monitor none -global sysbus-sm501.x-pixman=0 \ -qtest stdio -accel qtest The `x-pixman=0` setting forces the fallback C paths, making the issue easy to reproduce. ## Build: ./configure --target-list=sh4-softmmu --enable-asan --disable-werror \ --disable-docs --disable-guest-agent --disable-tools \ --disable-bsd-user --disable-linux-user ninja -C build qemu-system-sh4 ## Minimal qtest register sequence: writel 0x13f00010 0x00010001 writel 0x13f00008 0x1fff0001 writel 0x13f00004 0x00000000 writel 0x13f00000 0x00010000 writel 0x13f00040 0x00000000 writel 0x13f00044 0x00000000 writel 0x13f0001c 0x00000000 writel 0x13f0000c 0x880000cc ## ASAN result: ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x...6002,0x...8001) and [0x...6003,0x...8002) overlap #2 sm501_2d_engine_write sm501.c:1552 Address ... is a wild pointer inside of access range of size 0x1fff. SUMMARY: AddressSanitizer: memcpy-param-overlap sm501.c:1552 in sm501_2d_engine_write ABORTING ## Additional variant: I also validated a Rectangle Fill variant with: SM501_2D_FOREGROUND = 0x41414141 SM501_2D_CONTROL = 0x88010000 The destination-coordinate underflow happens before the command switch, so the Rectangle Fill fallback path can also receive an invalid destination offset with guest-controlled fill data. ## Suggested fix direction: Validate RTL coordinates before subtracting. For example, reject destination RTL operations where `dst_x + 1 < width` or `dst_y + 1 < height`, and reject BitBlt source RTL operations where `src_x + 1 < width` or `src_y + 1 < height`. It would also be useful to make the later bounds calculations overflow-safe. ## Attached: - sm501_rtl_underflow_poc.py.txt - REPORT.md Please let me know if you need any additional details or testing. [REPORT.md](/uploads/7cc199ca14efcd38bfda1ccbeaec7869/REPORT.md) [sm501_rtl_underflow_poc.py.txt](/uploads/04303b3aef4fb542d3be117d113db0b0/sm501_rtl_underflow_poc.py.txt)