QSB-118: Dom0 arbitrary code execution in qvm-copy-to-vm error reporting
https://www.qubes-os.org/news/2026/08/29/qsb-118/

We have published Qubes Security Bulletin (QSB) 118: Dom0 arbitrary code execution in qvm-copy-to-vm error reporting (https://github.com/QubesOS/qubes-secpack/blob/f65082c8211a421ed15a59219d6e54e93289fafb/QSBs/qsb-118-2026.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below, followed by a general explanation of this announcement and authentication instructions.

Qubes Security Bulletin 118


---===[ Qubes Security Bulletin 118 ]===---

2026-08-28

Dom0 arbitrary code execution in qvm-copy-to-vm error reporting

User action
------------

Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary
--------

If `qvm-copy-to-vm` is used to copy a file from dom0 to a malicious
qube, that qube can inject an arbitrary command into dom0.

Impact
-------

If an attacker has compromised a qube, and if the user initiates a
`qvm-copy-to-vm` call from dom0 to the compromised qube, then the
attacker can exploit this vulnerability in order to inject an arbitrary
command into dom0, which allows the attacker to take control of
Qubes OS.

Technical details
------------------

The `qvm-copy-to-vm` tool allows copying files from dom0 to a specified
qube. It uses the "qfile" protocol, which is a simplified archive
format, including simple file metadata (much simpler than `tar` or
`cpio`). The protocol also includes transfer confirmation at the end,
which is sent by the target back to the source. This confirmation
includes a checksum of all the transferred files, an error code (if
any), and the name of the last received file. In the case of an error,
as reported by the error code field, dom0 displays a GUI message that
includes the error information and the name of the affected file, as
reported by the target qube. The vulnerability exists in the processing
of that file name:

1. The `wait_for_result()` function calls `sanitize_remote_filename()`
on the received name before passing it to the error handler:

linux-utils/qrexec-lib/pack.c:

55 static void sanitize_remote_filename(char *untrusted_filename)
56 {
57 for (; *untrusted_filename; ++untrusted_filename) {
58 if (*untrusted_filename < ' ' ||
59 *untrusted_filename > '~' ||
60 *untrusted_filename == '"')
61 *untrusted_filename = '_';
62 }
63 }
64
65 void wait_for_result(void)
66 {
...
98 /* sanitize the remote filename */
99 sanitize_remote_filename(last_filename);
100
101 errno = hdr.error_code;
102 if (hdr.error_code != 0) {
103 switch (hdr.error_code) {
104 case EEXIST:
105 call_error_handler("A file named \"%s\" already exists in QubesIncoming dir", last_filename);
106 break;
...

2. Then, `call_error_handler()` calls the dom0 variant of the error
reporting function -- `gui_fatal()` -> `display_error()`, which uses
`system()` to launch the actual error dialog:

core-admin-linux/file-copy-vm/qfile-dom0-agent.c:

15 void display_error(const char *fmt, va_list args) {
16 char *dialog_cmd;
17 char buf[1024];
18 struct stat st_buf;
19 int ret;
20
21 (void) vsnprintf(buf, sizeof(buf), fmt, args);
22 ret = stat("/usr/bin/kdialog", &st_buf);
23 #define KDIALOG_CMD "kdialog --title 'File copy/move error' --sorry "
24 #define ZENITY_CMD "zenity --title 'File copy/move error' --warning --text "
25 if (asprintf(&dialog_cmd, "%s '%s: %s (error type: %s)'",
26 ret==0 ? KDIALOG_CMD : ZENITY_CMD,