The source excerpts below are from QEMU `master` at `ff1d2d19d7e24893e2012d879f8e73077e17b9bd`. ## Host environment - Operating system: Linux - OS/kernel version: 6.0 - Architecture: x86 - QEMU flavor: `qemu-system-riscv64` - QEMU version: qemu.git `ff1d2d19d7e24893e2012d879f8e73077e17b9bd` ## Emulated/Virtualized environment - Operating system: RISC-V guest issuing legacy console or DBCN SBI calls - Architecture: RISC-V - Accelerator: `KVM` - Relevant CPU/device configuration: Start QEMU with no serial backend, for example `-nodefaults -serial none` ## Description of problem ### Background and terminology KVM may exit to QEMU for emulation of SBI calls. Legacy console and the SBI Debug Console extension then forward bytes between guest memory and a QEMU character backend. The guest controls the SBI function arguments, while the user is allowed to start QEMU without a serial backend; both boundaries must be treated as untrusted inputs. ### Affected code path The affected implementation locations are: `target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() and kvm_riscv_handle_sbi_dbcn()` KVM routes SBI exits to `kvm_riscv_handle_sbi()`. Legacy getchar/putchar and all implemented DBCN functions call `serial_hd(0)->fe` without first checking whether `serial_hd(0)` returned a device. ### Current source evidence [target/riscv/kvm/kvm-cpu.c:1617](https://gitlab.com/qemu-project/qemu/-/blob/ff1d2d19d7e24893e2012d879f8e73077e17b9bd/target/riscv/kvm/kvm-cpu.c#L1617) ```c 1617 | 1618 | static void kvm_riscv_handle_sbi_dbcn(CPUState *cs, struct kvm_run *run) 1619 | { 1620 | const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED; 1621 | g_autofree uint8_t *buf = NULL; 1622 | RISCVCPU *cpu = RISCV_CPU(cs); 1623 | target_ulong num_bytes; 1624 | uint64_t addr; 1625 | unsigned char ch; 1626 | int ret; 1627 | 1628 | switch (run->riscv_sbi.function_id) { 1629 | case SBI_EXT_DBCN_CONSOLE_READ: 1630 | case SBI_EXT_DBCN_CONSOLE_WRITE: 1631 | num_bytes = run->riscv_sbi.args[0]; 1632 | 1633 | if (num_bytes == 0) { 1634 | run->riscv_sbi.ret[0] = SBI_SUCCESS; 1635 | run->riscv_sbi.ret[1] = 0; 1636 | break; 1637 | } 1638 | 1639 | addr = run->riscv_sbi.args[1]; 1640 | 1641 | /* 1642 | * Handle the case where a 32 bit CPU is running in a 1643 | * 64 bit addressing env. 1644 | */ 1645 | if (riscv_cpu_is_32bit(cpu)) { 1646 | addr |= (uint64_t)run->riscv_sbi.args[2] << 32; 1647 | } 1648 | 1649 | buf = g_malloc0(num_bytes); 1650 | 1651 | if (run->riscv_sbi.function_id == SBI_EXT_DBCN_CONSOLE_READ) { 1652 | ret = qemu_chr_fe_read_all(serial_hd(0)->fe, buf, num_bytes); 1653 | if (ret < 0) { 1654 | error_report("SBI_EXT_DBCN_CONSOLE_READ: error when " 1655 | "reading chardev"); 1656 | exit(1); 1657 | } 1658 | 1659 | address_space_write(cs->as, addr, attrs, buf, ret); 1660 | } else { 1661 | address_space_read(cs->as, addr, attrs, buf, num_bytes); 1662 | 1663 | ret = qemu_chr_fe_write_all(serial_hd(0)->fe, buf, num_bytes); 1664 | if (ret < 0) { 1665 | error_report("SBI_EXT_DBCN_CONSOLE_WRITE: error when " 1666 | "writing chardev"); 1667 | exit(1); 1668 | } 1669 | } 1670 | 1671 | run->riscv_sbi.ret[0] = SBI_SUCCESS; 1672 | run->riscv_sbi.ret[1] = ret; 1673 | break; 1674 | case SBI_EXT_DBCN_CONSOLE_WRITE_BYTE: 1675 | ch = run->riscv_sbi.args[0]; 1676 | ret = qemu_chr_fe_write_all(serial_hd(0)->fe, &ch, sizeof(ch)); 1677 | 1678 | if (ret < 0) { 1679 | error_report("SBI_EXT_DBCN_CONSOLE_WRITE_BYTE: error when " 1680 | "writing chardev"); 1681 | exit(1); 1682 | } 1683 | 1684 | run->riscv_sbi.ret[0] = SBI_SUCCESS; 1685 | run->riscv_sbi.ret[1] = 0; 1686 | break; 1687 | default: 1688 | run->riscv_sbi.ret[0] = SBI_ERR_NOT_SUPPORTED; 1689 | } 1690 | } ``` [target/riscv/kvm/kvm-cpu.c:1691](https://gitlab.com/qemu-project/qemu/-/blob/ff1d2d19d7e24893e2012d879f8e73077e17b9bd/target/riscv/kvm/kvm-cpu.c#L1691) ```c 1691 | 1692 | static int kvm_riscv_handle_sbi(CPUState *cs, struct kvm_run *run) 1693 | { 1694 | int ret = 0; 1695 | unsigned char ch; 1696 | switch (run->riscv_sbi.extension_id) { 1697 | case SBI_EXT_0_1_CONSOLE_PUTCHAR: 1698 | ch = run->riscv_sbi.args[0]; 1699 | qemu_chr_fe_write(serial_hd(0)->fe, &ch, sizeof(ch)); 1700 | break; 1701 | case SBI_EXT_0_1_CONSOLE_GETCHAR: 1702 | ret = qemu_chr_fe_read_all(serial_hd(0)->fe, &ch, sizeof(ch)); 1703 | if (ret == sizeof(ch)) { 1704 | run->riscv_sbi.ret[0] = ch; 1705 | } else { 1706 | run->riscv_sbi.ret[0] = -1; 1707 | } 1708 | ret = 0; 1709 | break; 1710 | case SBI_EXT_DBCN: 1711 | kvm_riscv_handle_sbi_dbcn(cs, run); 1712 | break; 1713 | default: 1714 | qemu_log_mask(LOG_UNIMP, 1715 | "%s: un-handled SBI EXIT, specific reasons is %lu\n", 1716 | __func__, run->riscv_sbi.extension_id); 1717 | ret = -1; 1718 | break; 1719 | } 1720 | return ret; 1721 | } 1722 | 1723 | static int kvm_riscv_handle_csr(CPUState *cs, struct kvm_run *run) ``` ### Root cause analysis QEMU permits a machine configuration with no serial backend. In that configuration `serial_hd(0)` may return NULL, but the KVM SBI exit handlers immediately dereference `->fe`. The guest chooses when to issue these SBI calls, so a missing optional frontend is converted into a host QEMU NULL dereference rather than an SBI error or defined no-console behavior. The reasoning, step by step: 1. The user starts the VM without serial device zero. 2. The guest executes a legacy console or Debug Console SBI call that exits to userspace. 3. QEMU evaluates `serial_hd(0)->fe` without a NULL check. 4. The QEMU process dereferences address zero and terminates instead of completing the SBI exit. ### Worked example and boundary cases A default serial backend masks this behavior. In a supported no-backend configuration, first confirm the SBI function is forwarded to userspace and serial_hd(0) is NULL. The dereference then occurs at backend resolution independently of the transfer length. A one-byte ordinary operation is enough to inspect the missing-backend path; no resource-exhaustion scenario is needed. ### Conditions needed to reach the problem - RISC-V KVM forwards the relevant SBI extension/function to QEMU. - No character backend is installed at serial slot zero. - The guest issues one of the affected console operations. ### Expected or potential effect - A guest action can terminate the host QEMU process for a supported command-line configuration. - The failure is masked by default machines that automatically create a serial backend. ### Expected behavior A supported -nodefaults/-serial none configuration must return an SBI error or discard output instead of dereferencing serial_hd(0). ## Steps to reproduce The following validation design covers the expected and current-code results. 1. start a minimal RISC-V KVM VM with `-nodefaults -serial none` and the other machine-specific boot arguments required by the test host. 2. From the guest, issue legacy SBI console putchar/getchar and DBCN read/write/write-byte calls one at a time. 3. Run QEMU under a debugger or sanitizer and record whether the process reaches `serial_hd(0)->fe` with a NULL device. 4. Repeat with a valid `-serial stdio` backend as a control. Expected result: A no-console configuration is handled without a host crash, using the SBI-defined error/sentinel behavior appropriate for each function. Current behavior: Every implemented console path dereferences `serial_hd(0)` unconditionally. ## Suggested fix direction Resolve serial device zero once at the handler boundary and handle NULL before accessing the frontend. Legacy getchar can return its no-character sentinel; DBCN functions should return an SBI error such as not-supported/failed according to the extension contract. Keep this fix separate from transfer-size handling. The fix should be covered by the following focused regression checks: - Every implemented legacy and DBCN function with no serial backend. - A normal serial backend control. - No process exit on character-backend read/write errors. ## References - QEMU source baseline: https://gitlab.com/qemu-project/qemu/-/commit/ff1d2d19d7e24893e2012d879f8e73077e17b9bd ## Additional information - Source baseline: QEMU `master` at `ff1d2d19d7e24893e2012d879f8e73077e17b9bd` (checked 2026-09-05).