Re: [Libguestfs] [PATCH nbdkit] New filter: tar.

On Tue, Jul 07, 2020 at 06:36:42PM +0100, Richard W.M. Jones wrote: Interesting crash caused here. I'm going to document this on the public mailing list so we can find it in future, but I do not offer a fix. I noticed during testing that the filter segfaulted if you used something like: nbdkit --filter=tar --filter=xz file disk.tar.xz tar-entry=disk and did a simple query of the export TWICE: qemu-img info nbd:localhost:10809 qemu-img info nbd:localhost:10809 Notice what I'm saying here is that the first qemu-img command worked and the second one caused nbdkit to segfault. The segfault turned out to be this assertion failure: 263 assert (h->exportsize <= INT64_MAX); /* Guaranteed by negotiation phase */ with this stack trace: #1 0x00007fd737780884 in abort () from /lib64/libc.so.6 #2 0x00007fd737780769 in __assert_fail_base.cold () from /lib64/libc.so.6 #3 0x00007fd73778ff86 in __assert_fail () from /lib64/libc.so.6 #4 0x00000000004057b0 in backend_valid_range (b=0x85dbf20, offset=512, count=512) at backend.c:263 #5 0x0000000000406488 in backend_pread (b=0x85dbf20, buf=0x85ec730, count=512, offset=512, flags=0, err=0x7fd736afaa78) at backend.c:478 #6 0x00007fd7372b3b94 in tar_pread (next_ops=0x424520 <next_ops>, nxdata=0x85dbf20, handle=0x85a3130, buf=0x85ec730, count=512, offs=0, flags=0, err=0x7fd736afaa78) at tar.c:315 #7 0x000000000040bdbc in filter_pread (b=0x85da790, handle=0x85a3130, buf=0x85ec730, count=512, offset=0, flags=0, err=0x7fd736afaa78) at filters.c:441 #8 0x0000000000406536 in backend_pread (b=0x85da790, buf=0x85ec730, count=512, offset=0, flags=0, err=0x7fd736afaa78) at backend.c:483 #9 0x00000000004119ad in handle_request (cmd=0, flags=0, offset=0, count=512, buf=0x85ec730, extents=0x0) at protocol.c:241 #10 0x0000000000412bf8 in protocol_recv_request_send_reply () at protocol.c:713 #11 0x0000000000408356 in handle_single_connection (sockin=7, sockout=7) at connections.c:175 #12 0x000000000041820f in start_thread (datav=0x85a1fc0) at sockets.c:337 #13 0x00007fd73792f479 in start_thread () from /lib64/libpthread.so.0 #14 0x00007fd73785cb53 in clone () from /lib64/libc.so.6 The problem is that the xz backend’s exportsize is not cached from a previous call to xz_get_size(), so when we come to try to validate the range the assert fails. The reason for this is tar_prepare only calls the underlying next_ops->get_size() on the very first connection, because on subsequent connections the offset/size has already been cached so we don't need to do the work in calculate_offset_of_entry, and calculate_offset_of_entry is what calls next_ops->get_size. Also tar_get_size doesn't call next_ops->get_size because it doesn't need the result, which would have been the second opportunity to cache exportsize. If neither of these things happen then the core server will crash. I have fixed this in my copy of the tar filter by calling next_ops->get_size in tar_get_size even though the result is not needed. I checked the other plugins and the suspicious ones were: - ext2 - partition - truncate - xz However I was not able to produce a test case that crashed any of them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW