## Host environment - Operating system: Linux - OS/kernel version: Linux 5.15.0-94-generic - Architecture: x86_64 - QEMU flavor: qemu-system-x86_64 - QEMU version: git master (commit b833716681, v11.0.0-2279-gb833716681, post-v11.0.0) - QEMU command line: qemu-system-x86_64 -M q35 -m 512M -device uefi-vars-x64 -nographic -monitor none -serial none -bios pc-bios/bios-256k.bin -qmp unix:/tmp/qmp.sock,server,nowait -qtest unix:/tmp/qtest.sock,server,nowait ## Emulated/Virtualized environment - Operating system: Linux - Architecture: x86_64 ## Description of problem I used source code analysis for initial discovery and confirmed the bug manually with a qtest-based PoC against an unmodified ASAN-enabled QEMU build. No automated tools (AI/LLM, static analysis, fuzzer) were used. uefi_vars_check_secure_boot() in hw/uefi/var-service-auth.c:274-302 does not guard SetupMode as read-only. In EDK2, SetupMode is an internal AuthVariableLib variable (mPlatformMode global) that the OS cannot write. QEMU's setup_mode_is_active() (auth.c:84-98) trusts the stored SetupMode variable's data[0] byte as the truth source, and uefi_vars_check_secure_boot has no read-only guard for SetupMode — only SecureBootEnable (auth.c:285-291, guarded by force_secure_boot) and CustomMode (auth.c:293-299, guarded by disable_custom_mode) are protected. An attacker who has enrolled a PK (entering USER_MODE, SetupMode=0) can write SetupMode=1 via SetVariable with attributes=BS|RT (0x06, no TIME_BASED_AUTHENTICATED_WRITE_ACCESS) through the unauthenticated else branch at var-service-vars.c:539-542 (g_malloc+memcpy, no auth check). This returns EFI_SUCCESS — it should return EFI_WRITE_PROTECTED. Once SetupMode=1 is stored, setup_mode_is_active() returns true. Any subsequent SetVariable(KEK/db/dbx, sigdb_attrs | TIME_BASED_AUTH) reaches uefi_vars_check_auth_2_sb() which at auth.c:192-195 returns EFI_SUCCESS without PKCS7 verification for any non-PK secure boot variable. The attacker-controlled siglist data is committed to the secure boot key database at auth.c:263-269. PoC output (unmodified ASAN QEMU build, qtest-driven, no guest OS): === Step 2: SetVariable(SetupMode=0) — TAMPER ATTEMPT === Reading status at offsets 0x18-0x28: [0x18] = 0x3 (mm_variable.function = SET_VARIABLE) [0x20] = 0x0 (mm_variable.status = EFI_SUCCESS) [0x28] = 0x8be4df61 (mm_variable_access.guid = EfiGlobalVariable) SetVariable(SetupMode=0) status: 0x0 [!!!] SetupMode WRITE SUCCEEDED — should be WRITE_PROTECTED Repro (qtest, no guest OS needed): 1. Boot: qemu-system-x86_64 -M q35 -m 512M -device uefi-vars-x64 \ -nographic -bios pc-bios/bios-256k.bin \ -qmp unix:/tmp/qmp.sock,server,nowait \ -qtest unix:/tmp/qtest.sock,server,nowait 2. uefi-vars-x64 auto-maps MMIO at 0xfef10000 (var-service-sysbus.c:93) 3. Write REG_BUFFER_SIZE=0x1000 to allocate DMA buffer (MMIO +0x04) 4. Build SetVariable(SetupMode) request: mm_header{EfiSmmVariableProtocolGuid} + mm_variable{function=3} + mm_variable_access{EfiGlobalVariable, u"SetupMode", attrs=0x06 (BS|RT)} + data=\x01 5. Write request to guest physical 0x10000000, set REG_DMA_BUFFER_ADDR_LO, write CMD_DMA_MM (0x02) to REG_CMD_STS 6. Read back mm_variable.status = 0x0 (EFI_SUCCESS — should be EFI_WRITE_PROTECTED) Impact: Secure Boot trust chain compromised. After enrolling a PK and entering USER_MODE, an attacker can tamper SetupMode back to SETUP_MODE, re-enabling the auth bypass at auth.c:192-195 to write KEK/db/dbx without valid PKCS7 signatures. Confirmed: SetVariable(SetupMode) returns EFI_SUCCESS. Theoretical: injecting malicious db certificate allows unsigned UEFI images to pass Secure Boot verification, enabling persistent bootkit. Requires prior PK enrollment (not default — default has no PK and SetupMode is already 1). Fix: treat SetupMode and CustomMode as host-internal state in uefi_vars_check_secure_boot, rejecting any guest SetVariable attempt on these mode flags (return EFI_WRITE_PROTECTED). This matches EDK2 semantics where SetupMode is an AuthVariableLib-internal read-only variable. Patch in progress. Automated reproducer attached: poc.py