GuestMount Was Working
by roebi＠kleimanup.com
*Ref:* www.libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
Hi,
I had this working just fine on one machine. Then upgraded to a similar
machine with more memory. Now it fails. I am trying to read files from
inside a successfully setup Linux Mint 22.1 Cinnamon QEMU VM for FreeDos.
- *Mark Kleiman*, www.KleimanUp.com Engineer Teacher
Today (latest version) I installed the libguestfs for "Debian/Ubuntu"
without error:
sudo apt-get install libguestfs-tools
Here is the command I used to capture the files from inside the VM image:
*roe@d2:/media/roe/kem/gho/fDos$* guestmount -a fDos14.img -m /dev/sda1 oBox
libguestfs: error: /usr/bin/supermin exited with error status 1.
To see full error messages you may need to enable debugging.
Do:
export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again. For further information, read:
http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
You can also run 'libguestfs-test-tool' and post the *complete* output
into a bug report or message to the libguestfs mailing list.
Here is the command again with trace:
*roe@d2:/media/roe/kem/gho/fDos$* export LIBGUESTFS_DEBUG=1
LIBGUESTFS_TRACE=1
*roe@d2:/media/roe/kem/gho/fDos$* guestmount -a fDos14.img -m /dev/sda1 oBox
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: create: flags = 0, handle = 0x5fa148f4f530, program = guestmount
libguestfs: trace: set_recovery_proc false
libguestfs: trace: set_recovery_proc = 0
libguestfs: trace: add_drive "fDos14.img"
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: max_disks
libguestfs: trace: max_disks = 255
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: version
libguestfs: trace: version = <struct guestfs_version = major: 1, minor:
52, release: 0, extra: , >
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
libguestfs: launch: program=guestmount
libguestfs: launch: version=1.52.0
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/tmp/libguestfsBNFbNm
libguestfs: launch: umask=0002
libguestfs: launch: euid=1000
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: begin building supermin appliance
libguestfs: run supermin
libguestfs: command: run: /usr/bin/supermin
libguestfs: command: run: \ --build
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ --if-newer
libguestfs: command: run: \ --lock /var/tmp/.guestfs-1000/lock
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d
libguestfs: command: run: \ -o /var/tmp/.guestfs-1000/appliance.d
supermin: version: 5.2.2
supermin: package handler: debian/dpkg
supermin: acquiring lock on /var/tmp/.guestfs-1000/lock
supermin: build: /usr/lib/x86_64-linux-gnu/guestfs/supermin.d
supermin: reading the supermin appliance
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz type gzip base
image (tar)
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/daemon.tar.gz type gzip
base image (tar)
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/excludefiles type
uncompressed excludefiles
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/hostfiles type uncompressed
hostfiles
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/init.tar.gz type gzip base
image (tar)
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages type uncompressed
packages
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-hfsplus type
uncompressed packages
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-reiserfs type
uncompressed packages
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-xfs type
uncompressed packages
supermin: build: visiting
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/udev-rules.tar.gz type gzip
base image (tar)
supermin: mapping package names to installed packages
supermin: resolving full list of package dependencies
supermin: build: 207 packages, including dependencies
supermin: build: 7970 files
supermin: build: 4266 files, after matching excludefiles
supermin: build: 4269 files, after adding hostfiles
supermin: build: 4269 files, after removing unreadable files
supermin: build: 4276 files, after munging
supermin: kernel: looking for kernel using environment variables ...
supermin: kernel: looking for kernels in /lib/modules/*/vmlinuz ...
supermin: kernel: looking for kernels in /boot ...
supermin: kernel: kernel version of /boot/vmlinuz-6.8.0-59-generic =
6.8.0-59-generic (from filename)
supermin: kernel: picked modules path /lib/modules/6.8.0-59-generic
supermin: kernel: kernel version of /boot/vmlinuz-6.8.0-58-generic =
6.8.0-58-generic (from filename)
supermin: kernel: picked modules path /lib/modules/6.8.0-58-generic
supermin: kernel: kernel version of /boot/vmlinuz-6.8.0-57-generic =
6.8.0-57-generic (from filename)
supermin: kernel: picked modules path /lib/modules/6.8.0-57-generic
supermin: kernel: kernel version of /boot/vmlinuz-6.8.0-51-generic =
6.8.0-51-generic (from content)
supermin: kernel: picked modules path /lib/modules/6.8.0-51-generic
supermin: kernel: picked vmlinuz /boot/vmlinuz-6.8.0-59-generic
supermin: kernel: kernel_version 6.8.0-59-generic
supermin: kernel: modpath /lib/modules/6.8.0-59-generic
cp: cannot open '/boot/vmlinuz-6.8.0-59-generic' for reading: Permission
denied
supermin: cp -p '/boot/vmlinuz-6.8.0-59-generic'
'/var/tmp/.guestfs-1000/appliance.d.orbyfl0l/kernel': command failed,
see earlier errors
libguestfs: error: /usr/bin/supermin exited with error status 1, see
debug messages above
libguestfs: trace: launch = -1 (error)
libguestfs: trace: close
libguestfs: closing guestfs handle 0x5fa148f4f530 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsBNFbNm
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
2 months
[NBDKIT SECURITY] two flaws with large block status requests
by Eric Blake
We have discovered two distinct but related potential Denial of
Service Attacks in nbdkit, when a client requests large block status.
Lifecycle
---------
For the first issue (general server flaw):
Reported: 2025-04-22 Fixed: 2025-05-08 Published: 2025-04-23
This has been assigned CVE-2025-47711.
For the second issue (blocksize filter flaw):
Reported: 2025-04-22 Fixed: 2025-05-08 Published: 2025-04-23
This has been assigned CVE-2025-47712.
Credit
------
The first issue was reported by Nikolay Ivanets <stenavin(a)gmail.com>;
the second issue was reported by Eric Blake while investigating the
first. Both issues were patched by Eric Blake <eblake(a)redhat.com>.
Reviewed by Rich Jones <rjones(a)redhat.com>.
Description
-----------
nbdkit is a Network Block Device (NBD) server with multiple plugins,
and includes the ability for plugins to report block status (also
known as extents) when a client requests NBD_CMD_BLOCK_STATUS. Nbdkit
does not yet support the NBD protocol extensions for 64-bit block
status, so it must convert 64-bit plugin information into 32-bit wire
responses.
However, two separate flaws in the handling of large block status
requests (near the 32-bit protocol limit of 4GiB) can result in the
server crashing with an assertion failure on a well-formed request
from the client. A malicious client could abuse these assertion
failures as a denial of service attack to prevent the server from
responding to other clients. Neither flaw can be exploited for any
effects beyond premature death of the server.
The first flaw was in the generic server code. If a client requests
exactly 2**32-1 bytes of block status, while a plugin implements an
.extents callback that reports a single extent with larger size, then
the server would crash rather than properly truncating the plugin's
response to the 32-bit protocol limit. No other request size triggers
the flaw, and the flaw is also avoided for any plugin or filter that
never reports a value larger than 32 bits in its .extents callback.
The second flaw was in the blocksize filter. If a client requests a
large block status length that is not aligned to the sector size
enforced by the filter, and rounding the request up to the next
aligned boundary overflowed a 32-bit number, then the filter would
crash the server rather than properly truncating the request to a
lower aligned boundary.
Mitigating both issues is the fact that most clients do not send
unaligned block status requests, and the attacks are not possible if
nbdkit is used with TLS to reject untrusted clients. The second issue
is also mitigated by the fact that many nbdkit command lines do not
need to use the blocksize filter.
Similarly, it is possible to prevent the attacks by arranging clients
and servers to use a trusted network (for example, using nbdkit -U for
a local Unix socket, rather than exposing the connection over TCP).
The generic server flaw affects a wider range of nbdkit releases
(since v1.11.10) than the blocksize filter flaw (since v1.21.16).
Fixed versions of nbdkit ensure that all valid client sizes to
NBD_CMD_BLOCK_STATUS are handled gracefully without assertion
failures.
Test if nbdkit is a vulnerable version
--------------------------------------
The following command lines demonstrate whether your version of nbdkit
is vulnerable to either issue:
Generic server flaw:
$ nbdkit eval get_size='echo 5G' extents='echo 0 4G 1; echo 4G 1G 2' \
--run 'nbdsh --base-allocation -u "$uri" \
-c "h.block_status(2**32-1, 0, lambda a,b,c,d: 0)"'
Blocksize filter flaw:
$ nbdkit eval get_size='echo 5G' extents='echo 0 4G 1; echo 4G 1G 2' \
--filter=blocksize minblock=512 \
--run 'nbdsh --base-allocation -u "$uri" \
-c "h.block_status(2**32-1, 0, lambda a,b,c,d: 0)"'
If either command reports an nbdkit assertion failure before nbdsh
mentions that the transport endpoint is not connected, then nbdkit is
flawed. A working nbdkit has no output and a 0 exit status.
Workarounds
-----------
In general, it is recommended to use TLS to avoid untrusted clients.
If TLS is not used, it is possible to use the blocksize-policy filter
(add '--filter=blocksize-policy blocksize-minimum=512' or similar to
the command line) to reject unaligned client requests prior to
reaching either assertion failure. However, use of the
blocksize-policy filter earlier in the command line than the blocksize
filter is atypical (the blocksize filter is designed to let clients
use unaligned requests, while the blocksize-policy filter is designed
to require clients to use aligned requests, so combining them changes
the semantics of what the server will allow from the client), and
placing the blocksize-policy filter after the blocksize filter does
not mitigate the second flaw.
Fixes
-----
The first flaw affects all stable nbdkit versions 1.12 through 1.42.2;
the second flaw affects all stable nbdkit versions 1.22 through
1.42.2. Both also affect development versions through 1.43.6. A fix
is available for the current development branch, as well as several of
the newer stable branches, as detailed below.
The first flaw was introduced at the time the .extents callback was
added in March 2019, in development release v1.11.10:
https://gitlab.com/nbdkit/nbdkit/-/commit/26455d452574f60119a79aea5a9f437...
The second flaw was introduced while fixing another .extents bug in
the blocksize filter in July 2020, in development release v1.21.16:
https://gitlab.com/nbdkit/nbdkit/-/commit/2680be00af8edd997e1c9b3765180ed...
Both patches were initially posted on April 23, 2025:
https://lists.libguestfs.org/archives/list/guestfs@lists.libguestfs.org/t...
* development branch (1.43)
https://gitlab.com/nbdkit/nbdkit/-/commit/e6f96bd1b77c0cc927ce6aeff650b52...
https://gitlab.com/nbdkit/nbdkit/-/commit/a486f88d1eea653ea88b0bf8804c482...
or use nbdkit >= 1.43.7 from
http://download.libguestfs.org/nbdkit/1.43-development/
* stable branch 1.42
https://gitlab.com/nbdkit/nbdkit/-/commit/c3c1950867ea8d9c2108ff066ed9e78...
https://gitlab.com/nbdkit/nbdkit/-/commit/c3ed72811aca5684490b198737b2f0b...
or use nbdkit >= 1.42.3 from
http://download.libguestfs.org/nbdkit/1.42-stable/
* stable branch 1.40
https://gitlab.com/nbdkit/nbdkit/-/commit/2959966cfa9e8675efea286eba12d09...
https://gitlab.com/nbdkit/nbdkit/-/commit/07986b5ce477dd504bd8cd11c7d455b...
or use nbdkit >= 1.40.6 from
http://download.libguestfs.org/nbdkit/1.40-stable/
* stable branch 1.38
https://gitlab.com/nbdkit/nbdkit/-/commit/e614d87fdf236ccf6a9c66ac0562064...
https://gitlab.com/nbdkit/nbdkit/-/commit/cf2dcbf3d06097d29693bd3943e9efc...
or use nbdkit >= 1.38.6 from
http://download.libguestfs.org/nbdkit/1.38-stable/
Feel free to request help if you have a reason to backport either
patch to an older branch.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
2 months, 1 week
