v1 was here: https://lists.gnu.org/archive/html/qemu-devel/2024-06/msg01609.html
Since then, I've applied with Red Hat to get a CVE assigned (a client not using TLS should never be able to cause the destination qemu to crash during live storage migration), and will update to include that number once it is assigned. But since the issue has already been on list, I see no need to further embargo this patch attempt. I've also concluded from my audit that Alexander's initial hunch was right: there's nothing simple we can do to prevent qio coroutines from reaching our callback into nbd_blockdev_client_closed() after a QMP nbd-server-stop (I could not find a graceful way to close the qio channel and then forcefully wait for the coroutine to finish), so that function has to be prepared to handle late clients, but the fix in patch 1 is a bit more involved than Alexander's attempt since we must also not corrupt a subsequent nbd-server-start. Patch 2 is insufficient on its own to prevent the problems, but reduces the amount of time that a client can hang on to server resources after nbd-server-stop (the client will see EPIPE rather than being able to carry on a prolonged NBD_OPT_* conversation). [I'm also aware of some Coverity analysis pointing to potential race conditions in block/nbd.c; if those need fixes, I hope to also post patches for those in time for inclusion in the same pull request that picks up this series] Eric Blake (3): nbd: CVE-XXX: Use cookie to track generation of nbd-server nbd: CVE-XXX: Close stray client sockets at server shutdown nbd: Minor style fixes include/block/nbd.h | 3 ++- blockdev-nbd.c | 39 ++++++++++++++++++++++++++++++++++----- nbd/server.c | 14 +++++++++----- qemu-nbd.c | 8 +++++--- 4 files changed, 50 insertions(+), 14 deletions(-) -- 2.45.2
