We have discovered a security flaw with potential minor impact in libnbd. Lifecycle --------- Reported: 2023-10-29 Fixed: 2023-10-31 Published: 2023-10-31 CVE-2023-5871 has been assigned due to a potential for a Denial of Service attack by a malicious server against certain versions of libnbd during nbd_block_status(3); it is considered a low severity flaw. Credit ------ Reported by Rich Jones (rjones(a)redhat.com) during fuzz tests, patched by Eric Blake <eblake(a)redhat.com&gt; Description ----------- libnbd is a Network Block Device (NBD) client library. The NBD protocol states that a client can negotiate with a server to enable 64-bit extended headers; when this negotiation is done, a server's reply to NBD_CMD_BLOCK_STATUS can include a flag field that does not fit in 32 bits. We recently added the nbd_block_status_64(3) API to libnbd to handle such server replies gracefully (exposing the full 64-bit reply to the application); but if an application still uses the older 32-bit nbd_block_status() API when the server sends a large flag value, a flaw in libnbd meant that the library could die with an assertion failure triggered by the server, rather than raising an EOVERFLOW error to indicate that the server's reply could not fit in the space provided by the application's choice of API. Test if libnbd is vulnerable ---------------------------- At this time, there are no known NBD servers that provide meta-contexts with 64-bit flags (most servers lack support for extended headers altogether; and all meta-contexts supported by the upcoming qemu 8.2 release are limited to 32-bit flag values), so it is unlikely to hit the issue in production when talking to a known server. However, the patch applied to libnbd for this issue includes instructions for applying a one-byte patch to convert qemu into a malicious server, to demonstrate that it is easy for an attacker to generate a malicious server attempting to exploit the Denial of Service vulnerability. Refer to the libnbd patch if you need instructions for producing a one-off qemu server that can be used for probing if libnbd is vulnerable; otherwise, it is recommended that you upgrade to the latest libnbd if you need the functionality provided by extended headers. Libnbd 1.16.x and earlier are not impacted (those versions gracefully reject an extended response from a malicious server as unknown, since they lack extended headers support). Workarounds ----------- As a mitigating factor, an application can be written to use only nbd_block_status_64() to ensure the assertion failure in nbd_block_status() cannot be reached. Compiling libnbd with assertions disabled will also eliminate the bug, although most distros follow our recommendation of leaving assertions enabled. Furthermore, no known production servers (such as nbd-server, qemu-nbd, nbdkit) support a meta-context that would include a 64-bit status flag. An application that insists on using TLS to connect only to a known-good server will never encounter a block status response that would trigger the assertion failure. Fixes ----- The assertion failure was introduced in libnbd v1.17.4 (commit 20dadb0e10). As of this email, all affected branches have been patched: * development branch (1.19) https://gitlab.com/nbdkit/libnbd/-/commit/177308adb17e81fce7c0f2b2fcf655c... or use libnbd >= 1.19.2 from http://download.libguestfs.org/libnbd/1.19-development/ * stable branch 1.18 https://gitlab.com/nbdkit/libnbd/-/commit/4451e5b61ca07771ceef3e012223779... or use libnbd >= 1.18.2 from http://download.libguestfs.org/libnbd/1.18-stable/ -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org