<!--This is the upstream QEMU issue tracker. If you are able to, it will greatly facilitate bug triage if you attempt to reproduce the problem with the latest qemu.git master built from source. See https://www.qemu.org/download/#source for instructions on how to do this. QEMU generally supports the last two releases advertised on https://www.qemu.org/. Problems with distro-packaged versions of QEMU older than this should be reported to the distribution instead. See https://www.qemu.org/contribute/report-a-bug/ for additional guidance. If this is a security issue, ensure this ticket is marked 'confidential' before submission. See https://www.qemu.org/contribute/security-process/ for additional guidance--> ## Host environment - Operating system: Arch Linux - OS/kernel version: Linux 0 7.1.8-hardened1-2-hardened #1 SMP PREEMPT_DYNAMIC Tue, 11 Aug 2026 09:16:17 +0000 x86_64 GNU/Linux - Architecture: x86_64 - QEMU flavor: qemu-system-x86_64 - QEMU version: 11.1.50 (v11.1.0-293-gfa19879df1) - QEMU command line: ``` qemu-system-x86_64 --no-reboot -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio -device pci-testdev -machine accel=tcg -smp 1 -kernel x86/emulator.flat ``` ## Emulated/Virtualized environment - Operating system: none/kvm-unit-tests bare-metal test binary - OS/kernel version: n/a - Architecture: x86_64 ## Description of problem Memory references implicitly using `SS` as their base segment, that being `RSP` or `RBP` relative addressing, must raise `#SS(0)` on a non-canonical address rather than a `#GP(0)`. Under TCG, they incorrectly raise a `#GP(0)`. The same test passes under KVM on the same host with the same QEMU binary. #### Test with TCG: ``` PASS: non-canonical memory access, should #GP(0), got #GP(0) PASS: Wanted CR2 '0xdecafbad', got '0xdecafbad FAIL: non-canonical rsp-based access, should #SS(0), got #GP(0) PASS: Wanted CR2 '0xdecafbad', got '0xdecafbad FAIL: non-canonical rbp-based access, should #SS(0), got #GP(0) PASS: Wanted CR2 '0xdecafbad', got '0xdecafbad ``` #### Test with KVM: ``` PASS: non-canonical memory access, should #GP(0), got #GP(0) PASS: Wanted CR2 '0xdecafbad', got '0xdecafbad PASS: non-canonical rsp-based access, should #SS(0), got #SS(0) PASS: Wanted CR2 '0xdecafbad', got '0xdecafbad PASS: non-canonical rbp-based access, should #SS(0), got #SS(0) PASS: Wanted CR2 '0xdecafbad', got '0xdecafbad ``` The canonicality check is in `get_physical_address()` in `target/i386/tcg/system/excp_helper.c`, which unconditionally uses `EXCP0D_GPF`: ```c if (in.pg_mode & PG_MODE_LMA) { /* test virtual address sign extension */ int shift = in.pg_mode & PG_MODE_LA57 ? 56 : 47; int64_t sext = (int64_t)addr >> shift; if (sext != 0 && sext != -1) { *err = (TranslateFault){ .exception_index = EXCP0D_GPF, /* non-canonical #GP doesn't change CR2 */ .cr2 = env->cr[2], }; return false; } } ``` This function is reached from `x86_cpu_tlb_fill()`, whose imputs are the linear addresses, `MMUAccessType` , and `mmu_idx`. None of these identify the segment the reference was made through, so the correct vector cannot be selected at this point. The required information does, however exist at translation time, `gen_lea_v_seg_dest()` in `target/i386/tcg/translate.c` receives `def_seg` as `R_SS` for `RSP`/`RBP` based addressing. However, in 64 bit mode, the segment identity is discarded before the addresses reach memory access because `has_base` is false for `SS`. In order to fix this, the originating segment has to be either carried down to the fault path, or the canonicality check has to be moved to translation time where `def_seg` is known. Furthermore, the non-canonical address always misses the TLB and reaches `tlb_fill`, so the check is on a slow path either way. I have not attempted to fix this and would welcome guidance on which approach (or an alternative solution) is preferred. I have found no prior reports of this on qemu-devel, the KVM list, or in git history. ## Steps to reproduce 1. Build QEMU from qemu.git master. 2. Build the kvm-unit-tests from kvm-unit-tests.git master for x86_64. 3. Run under TCG with the command line above, the specified two checks fail. 4. Re-run with `-machine accel=kvm`, both will pass. <!--Note: if this issue was discovered with the assistance of automated tooling LLM, static analysis, fuzzers), the reporter must disclose that in the description. The steps to reproduce, and any other findings, must be fully validated by the user of the tool prior to submission.--> ## Additional information The `CR2` behavior for these faults was fixed in df9a3372ddeb ("target/i386: Fix CR2 handling for non-canonical addresses") and is correct, the runs report the `CR2` values to match what the suite expects. This was found in the same kvm-unit-tests run as #4204, which reports a separate `MOV` to `SS` validation issue. The two appear to be independent defects in different code paths. Note that the test aborts shortly afterwards with an unrelated invalid handling of a jump to non-canonical address, reported in #125 , so any checks after that point in `emulator.flat` do not execute.