Automated-tool disclosure: This issue was found by automated fuzzing and static analysis; a human validated the finding and reproducer against the real qemu-system-arm binary. ## Host environment - QEMU source revision: `6333226c2abb72f31648c251624c56e70993d625` (describe string `v11.1.0-rc1-47-g6333226c2a`) - Target binary: authentic `qemu-system-arm` (arm-softmmu) - Compiler: Ubuntu clang 18 - Sanitizer: UBSan with `-fno-sanitize-recover=undefined` - Build flags: `CFLAGS="-O1 -g -fno-omit-frame-pointer -fno-sanitize-recover=undefined"` - Configure: `--enable-ubsan --disable-download --disable-werror --disable-docs --target-list=arm-softmmu` - Container base image: digest-pinned `ubuntu:24.04` - Isolation: all proof runs use `--network=none` (no live targets, production guests, credentials, or vendor endpoints were used) ## Emulated/Virtualized environment - Machine: `orangepi-pc,accel=qtest` (Allwinner H3 SoC emulation) - Accelerator: `qtest` (NOT a virtualization accelerator; see the eligibility caveat below) - Authority modeled: a guest controlling a write to the Allwinner H3 DRAMCOM control register at MMIO address `0x01c62000` ## Description of problem Primitive: guest-triggerable negative shift in QEMU Allwinner H3 DRAMC row mapping. On the `orangepi-pc` machine, a guest-controlled write to the DRAMCOM control register reaches `allwinner_h3_dramc_map_rows()`, which evaluates `1 << (row_bits - 3)` before checking that `row_bits` is at least 3. Writing `0x00000000` makes `row_bits == 1`, so the authentic `qemu-system-arm` UBSan build aborts with `shift exponent -2 is negative` at `hw/misc/allwinner-h3-dramc.c:81:27`. The demonstrated primitive is a bounded guest MMIO -> host undefined-behavior witness in the real system binary. It does not claim code execution, privilege escalation, or broader unsanitized impact. Root cause with source citation: At commit `6333226c2abb72f31648c251624c56e70993d625`, `allwinner_h3_dramcom_write()` dispatches `REG_DRAMCOM_CR` writes into `allwinner_h3_dramc_map_rows()` (`hw/misc/allwinner-h3-dramc.c:129-137`). It computes: ```c allwinner_h3_dramc_map_rows(s, ((val >> 4) & 0xf) + 1, ((val >> 2) & 0x1) + 2, 1 << (((val >> 8) & 0xf) + 3)); ``` Inside `allwinner_h3_dramc_map_rows()`, the first branch compares against: ```c if (s->ram_size == (1 << (row_bits - 3))) { ``` (`hw/misc/allwinner-h3-dramc.c:81`) For `val == 0`, the caller-derived `row_bits` equals `1`, so the expression evaluates `1 << -2`. `git blame` attributes the exact line to commit `b71d0385e97` (`hw/arm/allwinner-h3: add SDRAM controller device`). Bounded impact and explicit non-claims: Confirmed: - A guest-controlled write to `0x01c62000` on `orangepi-pc` reaches host undefined behavior in the real `qemu-system-arm` binary. - The demonstrated trigger value `0x00000000` causes UBSan to report a negative shift at `allwinner-h3-dramc.c:81:27`. - The primitive is guest-triggerable availability / memory-safety evidence in an emulation target. Not shown: - Unsanitized runtime behavior beyond the UBSan witness. - Code execution, privilege escalation, or cross-tenant compromise. - A claim that every other `DRAMCOM_CR` value is safe or unsafe. - A complete maintainer security-boundary decision; that remains QEMU triage. Suggested fix direction: reject or clamp `row_bits < 3` before evaluating `1 << (row_bits - 3)` in `allwinner_h3_dramc_map_rows()`. ## Steps to reproduce Run the qtest commands below against a UBSan-enabled qemu-system-arm build. Build command (offline container): ```sh docker run --rm --network=none \ --mount type=bind,src=<qemu-source-tree>,dst=/src,readonly \ --workdir /build <repro-toolchain-image> \ /bin/sh -c 'set -eux; CC=clang CFLAGS="-O1 -g -fno-omit-frame-pointer -fno-sanitize-recover=undefined" /src/configure --enable-ubsan --disable-download --disable-werror --disable-docs --target-list=arm-softmmu; ninja qemu-system-arm' ``` Trigger qtest script: ```text read 0x01c62000 0x4 write 0x01c62000 0x4 0x00000000 ``` Replay command: ```sh cat > /tmp/h3-trigger.qtest <<'EOF' read 0x01c62000 0x4 write 0x01c62000 0x4 0x00000000 EOF UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1 timeout --kill-after=1s 5s \ ./qemu-system-arm -display none -monitor none -serial none \ -machine orangepi-pc,accel=qtest -qtest stdio < /tmp/h3-trigger.qtest ``` Control input (read-only qtest MMIO access, expected clean): ```text read 0x01c62000 0x4 ``` The read-only control exits cleanly with no UBSan output. Adding the `write ... 0x00000000` step produces the UBSan report (the stable oracle is the file/line plus the negative-shift message, not the raw stack addresses). ## Additional information Observed UBSan output from the trigger run: ```text ../src/hw/misc/allwinner-h3-dramc.c:81:27: runtime error: shift exponent -2 is negative SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/hw/misc/allwinner-h3-dramc.c:81:27 ``` Source-history bounds: - Confirmed reproducing revision: `6333226c2abb72f31648c251624c56e70993d625` - Source primitive first seen: `b71d0385e97` - Exact behavior first seen: `b71d0385e97` - Earliest stable tag containing the primitive within local tag inventory: `v10.0.0` - Current head source status at the reproduced revision: still present, no lower-bound guard before the shift - Known fixed version: unknown within this budget Duplicate-search record (bounded local-history review using `git log --follow -- hw/misc/allwinner-h3-dramc.c` and `git log --all --grep='allwinner-h3-dramc|dramc|row_bits|negative shift|shift exponent'`): nearest result is commit `34d8df2a1d`, which adjusts the row-mirror arithmetic to force 64-bit multiplication but does not add a lower-bound guard before the negative shift. Duplicate classification: `none_found_within_budget`. Regression-test suggestion: add a qtest covering the read-only control and the `write 0x01c62000 0x4 0x00000000` trigger so the machine rejects or safely handles the malformed row-bits configuration without invoking undefined behavior. SHA-256 of the qtest trigger script and sanitizer output block above (for integrity reference, no file uploaded): - Trigger qtest script (`read 0x01c62000 0x4\nwrite 0x01c62000 0x4 0x00000000\n`): see the fenced block under Steps to reproduce. - UBSan output: see the fenced block immediately above. ### Eligibility caveat This report does not claim in-scope security-boundary status. The following facts are stated directly and honestly: - The `orangepi-pc` machine is **NOT** in QEMU's aarch64 virtualization use-case machine list. Per `docs/system/security.rst` in the QEMU source, the only aarch64 machine type listed for the virtualization use case is `virt`. - `qtest` is **not** a virtualization accelerator. The virtualization use case requires a virtualization accelerator like KVM or HVF; `accel=qtest` is a test/QMP-replay accelerator, not hardware-assisted virtualization. - Per QEMU's published security policy, bugs affecting the non-virtualization use case (emulation using the Tiny Code Generator, and by extension non-virtualization accelerators such as qtest) are **not considered security bugs at this time**. - This finding is therefore presented as a guest-triggerable emulator bug candidate, not as a confirmed security-boundary violation. The `orangepi-pc` Allwinner H3 emulation path falls under the non-virtualization use case as described in `docs/system/security.rst`. - Final eligibility and security-boundary significance — including any CVE assignment — is a QEMU maintainer triage decision. This report is submitted as a confidential bug report through QEMU's published reporting process for maintainer review; it is for the maintainers to decide whether it warrants the security process or is handled as a routine bug.