When a user sends a name length value of 0xffffffff, nbd-server will try
to allocate one more byte for the \0 at the end, but that will result in
an integer overflow and a malloc(0), with the resulting write being to a
dangling pointer.

Fix by constraining the string size to 4096 bytes, as recommended by the
protocol standard.

This issue exists in NBD_OPT_INFO/NBD_OPT_GO handling as well as in
NBD_OPT_EXPORT_NAME handling.

CVE-2022-26495

Reported-By: 王多 <duo.wang@chaitin.com>
Signed-Off-By: Wouter Verhelst <w@uter.be>
(cherry picked from commit 4e5c5d2e)

When len - sizeof(namelen) > 1024, we have a buffer overflow.

Fix by using the "consume" function, which was written for that purpose.

CVE-2022-26496

Reported-By: Dialluvioso <dialluvioso@protonmail.com>
Reported-By: 王多 <duo.wang@chaitin.com>
Signed-Off-By: Wouter Verhelst <w@uter.be>
(cherry picked from commit 3740ff7f)

Closes: gh-91

Josh Triplett authored Jul 01, 2020 and Wouter Verhelst committed Oct 06, 2020

Add an option to skip negotiation. Add an option to specify the device
size, required if using preinit.

Josh Triplett authored Jul 01, 2020 and Wouter Verhelst committed Oct 06, 2020

This allows forcing the block device to be read-only even if the server
would allow writes.

This list is no longer maintained, while the repology badge that we show
is updated automatically.

Jonathan Liu authored Mar 15, 2020 and Wouter Verhelst committed Mar 17, 2020

The netmask line can fail to parse when passed to getaddrinfo if it
contains whitespace such as newline when using glibc 2.29 and later.
This results in clients being denied access even though their IP
address is listed in the authorization file.

Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Wouter Verhelst <w@uter.be>

"not available on this platform" is rather weird, and probably too narrow a
choice. "not enabled at compile time" might be slightly more useful, and
nbd-server uses that for STARTTLS when it was disabled currently.

This might be a good idea, so explicitly allow for it.

Vladimir Sementsov-Ogievskiy authored Feb 04, 2020 and Wouter Verhelst committed Feb 07, 2020

max-block restriction make sense for NBD_CMD_WRITE and NBD_CMD_READ to
avoid big data transfer and long io operations at server side.
NBD_CMD_WRITE_ZEROES still may be realized on server through direct
writing zeroes, which may lead to long operation and huge allocation
and should be restricted by max-block.
Same for NBD_CMD_CACHE: long operation / big allocation.

Still, NBD_CMD_TRIM, NBD_CMD_BLOCK_STATUS and NBD_CMD_WRITE_ZEROES with
NBD_CMD_FLAG_FAST_ZERO set are over-restricted by it. So, for better
performance, drop these restrictions.

Note, that Qemu nbd server already works accordingly to this patch: it
doesn't check the restriction for NBD_CMD_TRIM, NBD_CMD_BLOCK_STATUS
and NBD_CMD_WRITE_ZEROES.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

When migrating to dpkg-source v3, we can't do source builds on salsa anymore.

$enable_manpages should be used instead of $enablemanpages

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

Coverity CID#1162721

For further information about discussion around this standard, see
this thread on the mailing list:
https://lists.debian.org/nbd/2019/05/msg00013.html



Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
[eblake: couple of typo fixes]
Signed-off-by: Eric Blake <eblake@redhat.com>

While it may be counterintuitive at first, the introduction of
NBD_CMD_WRITE_ZEROES and NBD_CMD_BLOCK_STATUS has caused a performance
regression in qemu [1], when copying a sparse file. When the
destination file must contain the same contents as the source, but it
is not known in advance whether the destination started life with all
zero content, then there are cases where it is faster to request a
bulk zero of the entire device followed by writing only the portions
of the device that are to contain data, as that results in fewer I/O
transactions overall. In fact, there are even situations where
trimming the entire device prior to writing zeroes may be faster than
bare write zero request [2]. However, if a bulk zero request ever
falls back to the same speed as a normal write, a bulk pre-zeroing
algorithm is actually a pessimization, as it ends up writing portions
of the disk twice.

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06389.html
[2] https://github.com/libguestfs/nbdkit/commit/407f8dde



Hence, it is desirable to have a way for clients to specify that a
particular write zero request is being attempted for a fast wipe, and
get an immediate failure if the zero request would otherwise take the
same time as a write.  Conversely, if the client is not performing a
pre-initialization pass, it is still more efficient in terms of
networking traffic to send NBD_CMD_WRITE_ZERO requests where the
server implements the fallback to the slower write, than it is for the
client to have to perform the fallback to send NBD_CMD_WRITE with a
zeroed buffer.

Add a protocol flag and corresponding transmission advertisement flag
to make it easier for clients to inform the server of their intent. If
the server advertises NBD_FLAG_SEND_FAST_ZERO, then it promises two
things: to perform a fallback to write when the client does not
request NBD_CMD_FLAG_FAST_ZERO (so that the client benefits from the
lower network overhead); and to fail quickly with ENOTSUP, preferably
without modifying the export, if the client requested the flag but the
server cannot write zeroes more efficiently than a normal write (so
that the client is not penalized with the time of writing data areas
of the disk twice).

Note that the semantics are chosen so that servers should advertise
the new flag whether or not they have fast zeroing (that is, this is
NOT the server advertising that it has fast zeroes, but rather
advertising that the client can get fast feedback as needed on whether
zeroing is fast).  It is also intentional that the new advertisement
includes a new errno value, ENOTSUP, with rules that this error should
not be returned for any pre-existing behaviors, must not happen when
the client does not request a fast zero, and must be returned quickly
if the client requested fast zero but anything other than the error
would not be fast; while leaving it possible for clients to
distinguish other errors like EINVAL if alignment constraints are not
met.  Clients should not send the flag unless the server advertised
support, but well-behaved servers should already be reporting EINVAL
to unrecognized flags. If the server does not advertise the new
feature, clients can safely fall back to assuming that writing zeroes
is no faster than normal writes (whether or not the assumption
actually holds).

Note that the Linux fallocate(2) interface may or may not be powerful
enough to easily determine if zeroing will be efficient - in
particular, FALLOC_FL_ZERO_RANGE in isolation does NOT give that
insight; likewise, for block devices, it is known that
ioctl(BLKZEROOUT) does NOT have a way for userspace to probe if it is
efficient or slow.  But with enough demand, the kernel may add another
FALLOC_FL_ flag to use with FALLOC_FL_ZERO_RANGE, and/or appropriate
ioctls with guaranteed ENOTSUP failures if a fast path cannot be
taken.  If a server cannot easily determine if write zeroes will be
efficient, the server should either fail all NBD_CMD_FLAG_FAST_ZERO
with ENOTSUP, or else choose to not advertise NBD_FLAG_SEND_FAST_ZERO.

Signed-off-by: Eric Blake <eblake@redhat.com>

Coverity CID#1238645

This should make things -Wimplicit-fallthrough safe.

Hopefully also takes care of Coverity CID#1238646

lseek might fail, so assert that it didn't before we try something else.

Coverity CID#1238648

Coverity CID#1287056

Coverity CID#1287057

We want to set everything to be 0, not '0' (which is 0x48).

Coverity CID#1485625

If inetd mode isn't active, we need to exit early when inetd mode is
being tested.

The proper way to do that is to use an #ifdef...#else...#endif. Not
doing so will work too, but adds dead code, which is not so useful.

Coverity CID#1485626

Blocksizes must be a multiple of 512 bytes. Croak when that's not the
case.

Also fixes Coverity CID#1485624, which is a division by zero when
blocksize is (or converts to) zero.

Shouldn't matter, really, but coverity disagrees. It's also generally a
better idea, I guess.

Coverity CID#1485623

Coverity CID#1485621

We accidentally forgot to add the -g short option to the #ifdef
HAVE_NETLINK case.

Fixes: gh-101

This text from https://en.wikipedia.org/wiki/Nagle%27s_algorithm
is telling:

"In any request-response application protocols where request data can
be larger than a packet, this can artificially impose a few hundred
milliseconds latency between the requester and the responder, even if
the requester has properly buffered the request data. Nagle's
algorithm should be disabled by the requester in this case. If the
response data can be larger than a packet, the responder should also
disable Nagle's algorithm so the requester can promptly receive the
whole response."

And we hit it in real life with libnbd/nbdkit - more than an order of
magnitude in slowdown results when trying to saturate a connection
with as many parallel requests as possible when Nagle's algorithm
introduces artificial delay waiting for the ACKs:
https://www.redhat.com/archives/libguestfs/2019-May/msg00237.html



Signed-off-by: Eric Blake <eblake@redhat.com>

Apparently this does things in the wrong order, so don't run
g_array_free to clean things

Otherwise that's a layering violation

Kevin Daudt authored May 23, 2019 and Wouter Verhelst committed May 23, 2019

In set_peername, when netaddr.ss_family == AF_UNIX. ai is never initialized.

On line 1733, freeaddrinfo is called unconditionally on ai, which might be NULL
in some cases.

The musl implementation of getaddrinfo started to segfault when you pass it
NULL. This caused some of the tests to fail on Alpine Linux, namely simple_test
inetd and unix.

This patch was enough to fix the issue

sigh, yes, I know.

The documentation already mentions how the server used to send raw
'errno' codes, even though those are not platform-independent.  But it
is worth adding mention that common practice in clients is to map any
unknown error code over the wire back to EINVAL.

Signed-off-by: Eric Blake <eblake@redhat.com>

It is intentional that we send NBD-specific error values over the
wire, which (due to history) happen to match particular Linux errno
values, but which may not match on other systems.  To make it more
obvious that a mapping is involved (both for the server converting
local errno values into wire values, and in clients converting wire
values back into any human messages via strerror() or similar), update
the protocol specification to refer to NBD errors with an NBD_E
prefix.

Signed-off-by: Eric Blake <eblake@redhat.com>