I've requested a CVE from Red Hat, and hope to have an assigned number soon. Meanwhile, we can get review started, to make sure this is ready to include in 9.1. 'qemu-img info' should never print untrusted data in a way that might take over a user's terminal.
There are probably other spots where qemu-img info is printing untrusted data (such as filenames), where we probably ought to use the same sanitization tactics as shown here. Identifying those spots would be a useful part of this review, and may mean a v2 that is even more extensive in the number of patches. In patch 1, I created mod_utf8_sanitize_len(), with the intent that I could sanitize just a prefix of a string without having to copy it into a NUL-terminated buffer. I didn't end up needing it in my current version of patch 2 (since the code was already copying to a NUL-terminated buffer for trace purposes), but we may find uses for it; in fact, it raises the question of whether any of our trace_ calls need to sanitize untrusted data (or whether we can rely on ALL trace engines to be doing that on our behalf, already). Eric Blake (2): util: Refactor json-writer's string sanitizer to be public qemu-img: CVE-XXX Sanitize untrusted output from NBD server include/qemu/unicode.h | 3 ++ nbd/client.c | 5 ++- qobject/json-writer.c | 47 +---------------------- util/unicode.c | 84 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 92 insertions(+), 47 deletions(-) -- 2.45.2
