On Tue, Apr 22, 2025 at 10:08:01PM +0300, Nikolay Ivanets wrote:
> nbdkit crashes when the client is trying to get extents with len=2^32-1.
> Here is client code (nbdsh):
>
> h.add_meta_context("base:allocation")
> h.connect_uri("nbd://localhost:10809/disk0-flat.vmdk")
Can you post the disk0-flag.vmdk image (or better, instructions for
how to create it?)
>
> def f(metacontext, offset, e, status):
> print(e)
>
> h.block_status(2**32-2, 0, f)
> [4294967295, 0] <--- OK
>
> h.block_status(2**32-1, 0, f) <-- FAIL
> Traceback (most recent call last):
> File "<console>", line 1, in <module>
> File "/usr/lib64/python3.12/site-packages/nbd.py", line 2775, in
> block_status
> return libnbdmod.block_status(self._o, count, offset, extent, flags)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> nbd.Error: nbd_block_status: block-status: command failed: Transport
> endpoint is not connected (ENOTCONN)
That is indeed undesirable behavior. libnbd is not at fault here; rather,...
>
> Server prints:
>
> nbdkit: file.8: debug: file: extents count=4294967295 offset=0 req_one=0
> nbdkit: ../../server/protocol.c:505: extents_to_block_descriptors:
> Assertion `e.length <= length' failed.
> Aborted (core dumped)
...this is an nbdkit bug where the plugin was able to do something we
weren't expecting.
>
> Why 2^32-2 is max len, and why nbdkit crashes with 2**32-1? It seems like a
> bad-behaviour client can crash the server. Or did I miss something?
It's something we need to fix in nbdkit, but I need to be able to
reproduce the problem to see where things went wrong.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
_______________________________________________
Libguestfs mailing list -- guestfs@lists.libguestfs.org
To unsubscribe send an email to guestfs-le...@lists.libguestfs.org
