On Thu, Aug 01, 2024 at 08:32:06PM GMT, Eric Blake wrote: > As part of the QMP command nbd-server-start, the blockdev code was > creating a single global nbd_server object, and telling the qio code > to accept one or more client connections to the exposed listener > socket. But even though we tear down the listener socket during a > subsequent QMP nbd-server-stop, the qio code has handed off to a > coroutine that may be executing asynchronously with the server > shutdown, such that a client that connects to the socket before > nbd-server-stop but delays disconnect or completion of the NBD > handshake until after the followup QMP command can result in the > nbd_blockdev_client_closed() callback running after nbd_server has > already been torn down, causing a SEGV. Worse, if a second nbd_server > object is created (possibly on a different socket address), a late > client resolution from the first server can subtly interfere with the > second server. This can be abused by a malicious client that does not > know TLS secrets to cause qemu to SEGV after a legitimate client has > concluded storage migration to a destination qemu, which can be turned > into a denial of service attack even when qemu is set up to require > only TLS clients.
Now assigned CVE-2024-7409; I'll make sure that is mentioned in the commit message, whether a v2 is needed or whether this gets a positive review as-is modulo the reference. I have not (yet?) determined how long the bug has existed, but note that the code in question appears unchanged since at least qemu 6.0 (from 2021), and probably predates that, so it is long-standing. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
