[Libguestfs] LIBNBD SECURITY: Silent image corruption with nbdcopy

Eric Blake eblake at redhat.com
Mon Feb 7 19:40:18 UTC 2022

We have discovered a security flaw with potential moderate impact in


Reported: 2022-01-24  Fixed: 2022-02-04  Published: 2022-01-27

This has been assigned CVE-2022-0485.


Reported by Nir Soffer <nsoffer at redhat.com> and patched by Eric Blake
<eblake at redhat.com>


libnbd is a Network Block Device (NBD) client library.  nbdcopy is an
application shipped as part of the libnbd project designed to copy
files (typically disk images) where at least one of the source or
destination locations is an NBD server.

A flaw in the nbdcopy program silently ignored any asynchronous read
or write errors reported by an NBD server.  With no error messages and
no change to the exit status, a client of the nbdcopy application has
no indication that the corruption occurred, where the loss of data
integrity may have further implications in a denial of service attack
against disk images.  What's more, in some NBD client/server
configurations, the data that nbdcopy writes to the destination image
could come from uninitialized heap data in the nbdcopy process, where
the leaked information may aid in mounting a more sophisticated attack
against a machine using a long-running nbdcopy.

If TLS is not in use, a meddler-in-the-middler attacker can easily
corrupt the destination image by faking error replies to NBD read and
write commands.  But even when TLS is in use, the nature of the flaw
means that nbdcopy cannot detect legitimate error reports from the
server.  Furthermore, even though nbdcopy attempts to detect abrupt
disconnection of a TLS connection, the nature of asynchronous commands
means that we were unable to rule out whether a well-timed MitM
attacker could cause undetected corruption near the end of a copy
process by aborting a TLS stream at the right moment, even without
having access to the content of the TLS stream.

Test if libnbd is vulnerable

With nbdkit 1.14 or later installed, the following serves as an easy
test of the vulnerability:

$ nbdkit -U - --filter=error pattern size=1M error-pread-rate=1 \
  --run 'nbdcopy $uri null:' && echo vulnerable

The error messages printed from nbdkit demonstrate the failed NBD
transactions.  Where a vulnerable version of nbdcopy ignores those
errors and results in 'vulnerable' being printed to stdout, a fixed
version will diagnose a read failure to stderr.


Use of 'nbdcopy --synchronous' will avoid undected data corruption,
but comes at a potential performance cost by avoiding the speed
benefits of asynchronous operations.  If your version of nbdcopy lacks
the '--synchronous' command-line option (all 1.4.x releases), it is
not vulnerable.

Connecting a vulnerable version of nbdcopy to an NBD server that
supports structured replies by default (such as qemu-nbd 2.11 or
nbdkit 1.12 and newer) does not eliminate the risk of data corruption
on an error, but is sufficient to guarantee that any corruptions will
either read as all zeroes or else as prior contents of the destination
image.  This is safer than connecting nbdcopy to an NBD server that
lacks structured replies (such as nbd-server 3.23, current as of this
notice), where the data corruption could also leak heap contents from
the nbdcopy process.

Although the use of TLS does not avoid the bug, it is still
recommended to use TLS when utilizing nbdcopy to copy files across
machines, so that the NBD server can be trusted to not be malicious.

It is recommended to apply the fix or upgrade to a fixed version.


The flaw was introduced in libnbd 1.5.6 (commit bc896eec4d), when
nbdcopy gained the ability to default to using asynchronous NBD reads
and writes.  A fix for the missing error detection is available for
all affected stable branches, and the current development branch.

However, note that the stable-1.6 branch of libnbd has other known
data corruption bugs when communicating with an NBD server that
supports trim operations, which were repaired for 1.8 but not
backported to any 1.6.x release.  While the trim bug did not amount to
a CVE, if your reason for upgrading libnbd is to get a version of
nbdcopy that avoids known data corruption issues, it is recommended
that you use a newer release.

* development branch (1.11)

  or use libnbd >= 1.11.8 from

* stable branch 1.10

  or use libnbd >= 1.10.4 from

* stable branch 1.8

  or use libnbd >= 1.8.7 from

* stable branch 1.6

  or use libnbd >= 1.6.6 from

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

More information about the Libguestfs mailing list