.\" Automatically generated by Podwrapper::Man 1.48.6 (Pod::Simple 3.43)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "guestfs-security 1"
.TH guestfs-security 1 "2022-11-28" "libguestfs-1.48.6" "Virtualization Support"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
guestfs\-security \- security of libguestfs
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
This manual page discusses security implications of using libguestfs,
particularly with untrusted or malicious guests or disk images.
.SH "REPORTING SECURITY PROBLEMS"
.IX Header "REPORTING SECURITY PROBLEMS"
If you wish to privately report a security issue, please follow the
Red Hat security procedure at
https://access.redhat.com/security/team/contact
.PP
If the security problem is not so serious, you can simply file a bug
(see \*(L"\s-1BUGS\*(R"\s0 below), or send an email to our mailing list
(https://www.redhat.com/mailman/listinfo/libguestfs).  You do not
need to subscribe to the mailing list to send email, but there will be
a delay while the message is moderated.
.SH "GENERAL ISSUES"
.IX Header "GENERAL ISSUES"
.SS "Security of mounting filesystems"
.IX Subsection "Security of mounting filesystems"
You should never mount an untrusted guest filesystem directly on your
host kernel (eg. using loopback or kpartx).
.PP
When you mount a filesystem, mistakes in the kernel filesystem (\s-1VFS\s0)
can be escalated into exploits by attackers creating a malicious
filesystem.  These exploits are very severe for two reasons.  Firstly
there are very many filesystem drivers in the kernel, and many of them
are infrequently used and not much developer attention has been paid
to the code.  Linux userspace helps potential crackers by detecting
the filesystem type and automatically choosing the right \s-1VFS\s0 driver,
even if that filesystem type is unexpected.  Secondly, a kernel-level
exploit is like a local root exploit (worse in some ways), giving
immediate and total access to the system right down to the hardware
level.
.PP
These exploits can be present in the kernel for a very long time
(https://lwn.net/Articles/538898/).
.PP
Libguestfs provides a layered approach to protecting you from
exploits:
.PP
.Vb 9
\&   untrusted filesystem
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&   appliance kernel
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&   qemu process running as non\-root
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&   sVirt [if using libvirt + SELinux]
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&   host kernel
.Ve
.PP
We run a Linux kernel inside a qemu virtual machine, usually running
as a non-root user.  The attacker would need to write a filesystem
which first exploited the kernel, and then exploited either qemu
virtualization (eg. a faulty qemu driver) or the libguestfs protocol,
and finally to be as serious as the host kernel exploit it would need
to escalate its privileges to root.  Additionally if you use the
libvirt back end and SELinux, sVirt is used to confine the qemu
process.  This multi-step escalation, performed by a static piece of
data, is thought to be extremely hard to do, although we never say
‘never’ about security issues.
.PP
Callers can also reduce the attack surface by forcing the filesystem
type when mounting (use \*(L"guestfs_mount_vfs\*(R" in \fBguestfs\fR\|(3)).
.SS "General security considerations"
.IX Subsection "General security considerations"
Be careful with any files or data that you download from a guest (by
\&\*(L"download\*(R" we mean not just the \*(L"guestfs_download\*(R" in \fBguestfs\fR\|(3) command
but any command that reads files, filenames, directories or anything
else from a disk image).  An attacker could manipulate the data to
fool your program into doing the wrong thing.  Consider cases such as:
.IP "\(bu" 4
the data (file etc) not being present
.IP "\(bu" 4
being present but empty
.IP "\(bu" 4
being much larger than normal
.IP "\(bu" 4
containing arbitrary 8 bit data
.IP "\(bu" 4
being in an unexpected character encoding
.IP "\(bu" 4
containing homoglyphs.
.SS "Protocol security"
.IX Subsection "Protocol security"
The protocol is designed to be secure, being based on \s-1RFC 4506\s0 (\s-1XDR\s0)
with a defined upper message size.  However a program that uses
libguestfs must also take care \- for example you can write a program
that downloads a binary from a disk image and executes it locally, and
no amount of protocol security will save you from the consequences.
.SS "Inspection security"
.IX Subsection "Inspection security"
Parts of the inspection \s-1API\s0 (see \*(L"\s-1INSPECTION\*(R"\s0 in \fBguestfs\fR\|(3)) return
untrusted strings directly from the guest, and these could contain any
8 bit data.  Callers should be careful to escape these before printing
them to a structured file (for example, use \s-1HTML\s0 escaping if creating
a web page).
.PP
Guest configuration may be altered in unusual ways by the
administrator of the virtual machine, and may not reflect reality
(particularly for untrusted or actively malicious guests).  For
example we parse the hostname from configuration files like
\&\fI/etc/sysconfig/network\fR that we find in the guest, but the guest
administrator can easily manipulate these files to provide the wrong
hostname.
.PP
The inspection \s-1API\s0 parses guest configuration using two external
libraries: Augeas (Linux configuration) and hivex (Windows Registry).
Both are designed to be robust in the face of malicious data, although
denial of service attacks are still possible, for example with
oversized configuration files.
.SS "Running untrusted guest commands"
.IX Subsection "Running untrusted guest commands"
Be very cautious about running commands from the guest.  By running a
command in the guest, you are giving \s-1CPU\s0 time to a binary that you do
not control, under the same user account as the library, albeit
wrapped in qemu virtualization.  More information and alternatives can
be found in \*(L"\s-1RUNNING COMMANDS\*(R"\s0 in \fBguestfs\fR\|(3).
.SH "HISTORICAL SECURITY ISSUES IN LIBGUESTFS"
.IX Header "HISTORICAL SECURITY ISSUES IN LIBGUESTFS"
.SS "\s-1CVE\-2010\-3851\s0"
.IX Subsection "CVE-2010-3851"
https://bugzilla.redhat.com/642934
.PP
This security bug concerns the automatic disk format detection that
qemu does on disk images.
.PP
A raw disk image is just the raw bytes, there is no header.  Other
disk images like qcow2 contain a special header.  Qemu deals with this
by looking for one of the known headers, and if none is found then
assuming the disk image must be raw.
.PP
This allows a guest which has been given a raw disk image to write
some other header.  At next boot (or when the disk image is accessed
by libguestfs) qemu would do autodetection and think the disk image
format was, say, qcow2 based on the header written by the guest.
.PP
This in itself would not be a problem, but qcow2 offers many features,
one of which is to allow a disk image to refer to another image
(called the \*(L"backing disk\*(R").  It does this by placing the path to the
backing disk into the qcow2 header.  This path is not validated and
could point to any host file (eg. \*(L"/etc/passwd\*(R").  The backing disk is
then exposed through \*(L"holes\*(R" in the qcow2 disk image, which of course
is completely under the control of the attacker.
.PP
In libguestfs this is rather hard to exploit except under two
circumstances:
.IP "1." 4
You have enabled the network or have opened the disk in write mode.
.IP "2." 4
You are also running untrusted code from the guest (see
\&\*(L"\s-1RUNNING COMMANDS\*(R"\s0 in \fBguestfs\fR\|(3)).
.PP
The way to avoid this is to specify the expected disk format when
adding disks (the optional \f(CW\*(C`format\*(C'\fR option to
\&\*(L"guestfs_add_drive_opts\*(R" in \fBguestfs\fR\|(3)).  You should always do this if
the disk is raw format, and it’s a good idea for other cases too.
(See also \*(L"\s-1DISK IMAGE FORMATS\*(R"\s0 in \fBguestfs\fR\|(3)).
.PP
For disks added from libvirt using calls like
\&\*(L"guestfs_add_domain\*(R" in \fBguestfs\fR\|(3), the format is fetched from libvirt
and passed through.
.PP
For libguestfs tools, use the \fI\-\-format\fR command line parameter as
appropriate.
.SS "\s-1CVE\-2011\-4127\s0"
.IX Subsection "CVE-2011-4127"
https://bugzilla.redhat.com/752375
.PP
This is a bug in the kernel which allowed guests to overwrite
parts of the host’s drives which they should not normally
have access to.
.PP
It is sufficient to update libguestfs to any version ≥ 1.16 which
contains a change that mitigates the problem.
.SS "\s-1CVE\-2012\-2690\s0"
.IX Subsection "CVE-2012-2690"
https://bugzilla.redhat.com/831117
.PP
Old versions of both virt-edit and the guestfish \f(CW\*(C`edit\*(C'\fR command
created a new file containing the changes but did not set the
permissions, etc of the new file to match the old one.  The result of
this was that if you edited a security sensitive file such as
\&\fI/etc/shadow\fR then it would be left world-readable after the edit.
.PP
It is sufficient to update libguestfs to any version ≥ 1.16.
.SS "\s-1CVE\-2013\-2124\s0"
.IX Subsection "CVE-2013-2124"
https://bugzilla.redhat.com/968306
.PP
This security bug was a flaw in inspection where an untrusted guest
using a specially crafted file in the guest \s-1OS\s0 could cause a
double-free in the C library (denial of service).
.PP
It is sufficient to update libguestfs to a version that is not
vulnerable: libguestfs ≥ 1.20.8, ≥ 1.22.2 or ≥ 1.23.2.
.SS "\s-1CVE\-2013\-4419\s0"
.IX Subsection "CVE-2013-4419"
https://bugzilla.redhat.com/1016960
.PP
When using the \fBguestfish\fR\|(1) \fI\-\-remote\fR or guestfish \fI\-\-listen\fR
options, guestfish would create a socket in a known location
(\fI/tmp/.guestfish\-$UID/socket\-$PID\fR).
.PP
The location has to be a known one in order for both ends to
communicate.  However no checking was done that the containing
directory (\fI/tmp/.guestfish\-$UID\fR) is owned by the user.  Thus
another user could create this directory and potentially hijack
sockets owned by another user’s guestfish client or server.
.PP
It is sufficient to update libguestfs to a version that is not
vulnerable: libguestfs ≥ 1.20.12, ≥ 1.22.7 or ≥ 1.24.
.SS "Denial of service when inspecting disk images with corrupt btrfs volumes"
.IX Subsection "Denial of service when inspecting disk images with corrupt btrfs volumes"
It was possible to crash libguestfs (and programs that use libguestfs
as a library) by presenting a disk image containing a corrupt btrfs
volume.
.PP
This was caused by a \s-1NULL\s0 pointer dereference causing a denial of
service, and is not thought to be exploitable any further.
.PP
See commit d70ceb4cbea165c960710576efac5a5716055486 for the fix.  This
fix is included in libguestfs stable branches ≥ 1.26.0, ≥ 1.24.6 and ≥ 1.22.8, and also in \s-1RHEL\s0 ≥ 7.0.
Earlier versions of libguestfs are not vulnerable.
.SS "\s-1CVE\-2014\-0191\s0"
.IX Subsection "CVE-2014-0191"
Libguestfs previously used unsafe libxml2 APIs for parsing libvirt
\&\s-1XML.\s0  These APIs defaulted to allowing network connections to be made
when certain \s-1XML\s0 documents were presented.  Using a malformed \s-1XML\s0
document it was also possible to exhaust all \s-1CPU,\s0 memory or file
descriptors on the machine.
.PP
Since the libvirt \s-1XML\s0 comes from a trusted source (the libvirt daemon)
it is not thought that this could have been exploitable.
.PP
This was fixed in libguestfs ≥ 1.27.9 and the fix was backported
to stable versions ≥ 1.26.2, ≥ 1.24.9, ≥ 1.22.10 and ≥
1.20.13.
.SS "Shellshock (bash \s-1CVE\-2014\-6271\s0)"
.IX Subsection "Shellshock (bash CVE-2014-6271)"
This bash bug indirectly affects libguestfs.  For more information
see:
https://www.redhat.com/archives/libguestfs/2014\-September/msg00252.html
.SS "\s-1CVE\-2014\-8484\s0"
.IX Subsection "CVE-2014-8484"
.SS "\s-1CVE\-2014\-8485\s0"
.IX Subsection "CVE-2014-8485"
These two bugs in binutils affect the \s-1GNU\s0 \fBstrings\fR\|(1) program, and
thus the \*(L"guestfs_strings\*(R" in \fBguestfs\fR\|(3) and
\&\*(L"guestfs_strings_e\*(R" in \fBguestfs\fR\|(3) APIs in libguestfs.  Running strings
on an untrusted file could cause arbitrary code execution (confined to
the libguestfs appliance).
.PP
In libguestfs ≥ 1.29.5 and ≥ 1.28.3, libguestfs uses the
\&\f(CW\*(C`strings\*(C'\fR \fI\-a\fR option to avoid \s-1BFD\s0 parsing on the file.
.SS "\s-1CVE\-2015\-5745\s0"
.IX Subsection "CVE-2015-5745"
https://bugzilla.redhat.com/show_bug.cgi?id=1251157
.PP
This is not a vulnerability in libguestfs, but because we always give
a virtio-serial port to each guest (since that is how guest-host
communication happens), an escalation from the appliance to the host
qemu process is possible.  This could affect you if:
.IP "\(bu" 4
your libguestfs program runs untrusted programs out of the guest
(using \*(L"guestfs_sh\*(R" in \fBguestfs\fR\|(3) etc), or
.IP "\(bu" 4
another exploit was found in (for example) kernel filesystem code that
allowed a malformed filesystem to take over the appliance.
.PP
If you use sVirt to confine qemu, that would thwart some attacks.
.SS "Permissions of \fI.ssh\fP and \fI.ssh/authorized_keys\fP"
.IX Subsection "Permissions of .ssh and .ssh/authorized_keys"
https://bugzilla.redhat.com/1260778
.PP
The tools \fBvirt\-customize\fR\|(1), \fBvirt\-sysprep\fR\|(1) and
\&\fBvirt\-builder\fR\|(1) have an \fI\-\-ssh\-inject\fR option for injecting an \s-1SSH\s0
key into virtual machine disk images.  They may create a \fI~user/.ssh\fR
directory and \fI~user/.ssh/authorized_keys\fR file in the guest to do
this.
.PP
In libguestfs < 1.31.5 and libguestfs < 1.30.2, the new
directory and file would get mode \f(CW0755\fR and mode \f(CW0644\fR
respectively.  However these permissions (especially for
\&\fI~user/.ssh\fR) are wider than the permissions that OpenSSH uses.  In
current libguestfs, the directory and file are created with mode
\&\f(CW0700\fR and mode \f(CW0600\fR.
.SS "\s-1CVE\-2015\-8869\s0"
.IX Subsection "CVE-2015-8869"
https://bugzilla.redhat.com/CVE\-2015\-8869
.PP
This vulnerability in OCaml might affect virt tools written in the
OCaml programming language.  It affects only 64 bit platforms.
Because this bug affects code generation it is difficult to predict
which precise software could be affected, and therefore our
recommendation is that you recompile libguestfs using a version of the
OCaml compiler where this bug has been fixed (or ask your Linux distro
to do the same).
.SS "\s-1CVE\-2017\-5208, CVE\-2017\-5331, CVE\-2017\-5332, CVE\-2017\-5333, CVE\-2017\-6009, CVE\-2017\-6010, CVE\-2017\-6011\s0"
.IX Subsection "CVE-2017-5208, CVE-2017-5331, CVE-2017-5332, CVE-2017-5333, CVE-2017-6009, CVE-2017-6010, CVE-2017-6011"
Multiple vulnerabilities in the \fBwrestool\fR\|(1) program in the
\&\f(CW\*(C`icoutils\*(C'\fR package can be exploited for local code execution on the
host.
.PP
When libguestfs inspection (see \*(L"Inspection security\*(R" above) detects
a Windows \s-1XP\s0 or Windows 7 guest and is asked to find an associated
icon for the guest, it will download an untrusted file from the guest
and run \f(CW\*(C`wrestool \-x\*(C'\fR on that file.  This can lead to local code
execution on the host.  Any disk image or guest can be crafted to look
like a Windows guest to libguestfs inspection, so just because you do
not have Windows guests does not help.
.PP
Any program calling the libguestfs \s-1API\s0 \f(CW\*(C`guestfs_inspect_get_icon\*(C'\fR
could be vulnerable.  This includes \fBvirt\-inspector\fR\|(1) and
\&\fBvirt\-manager\fR\|(1).
.PP
The solution is to update to the non-vulnerable version of icoutils
(at least 0.31.1).
.SS "\s-1CVE\-2017\-7244, CVE\-2017\-7245, CVE\-2017\-7246\s0"
.IX Subsection "CVE-2017-7244, CVE-2017-7245, CVE-2017-7246"
Multiple vulnerabilities in \s-1PCRE\s0 could be exploited to crash
libguestfs (ie. cause a denial of service) when performing inspection
on an untrusted virtual machine.
.PP
The solution is to update to a version of \s-1PCRE\s0 with these bugs fixed
(upstream version ≥ 8.41).
.SS "\s-1CVE\-2018\-11806\s0"
.IX Subsection "CVE-2018-11806"
Vulnerabilities affecting qemu user networking (\s-1SLIRP\s0) allow a
malicious filesystem image to take control of qemu and from there
attack the host.
.PP
This affects libguestfs when the backend is set to \f(CW\*(C`direct\*(C'\fR \fIand\fR
networking is enabled.
.PP
The direct backend is the default upstream, but not in some downstream
Linux distributions including Fedora, Red Hat Enterprise Linux and
CentOS.  It might also have been selected if you set the
\&\f(CW\*(C`LIBGUESTFS_BACKEND=direct\*(C'\fR environment variable or called
\&\f(CW\*(C`guestfs_set_backend (g, "direct")\*(C'\fR.
.PP
Networking is enabled automatically by some tools
(eg. \fBvirt\-builder\fR\|(1)), or is enabled if your code called
\&\f(CW\*(C`guestfs_set_network (g, 1)\*(C'\fR (which is not the default).
.PP
The libvirt backend is not affected.
.PP
The solution is to update qemu to a version containing the fix (see
https://lists.gnu.org/archive/html/qemu\-devel/2018\-06/msg01012.html).
.SS "\s-1CVE\-2022\-2211\s0"
.IX Subsection "CVE-2022-2211"
https://bugzilla.redhat.com/CVE\-2022\-2211
.PP
The \f(CW\*(C`get_keys\*(C'\fR function in \fIlibguestfs\-common/options/keys.c\fR collects
those \fI\-\-key\fR options from the command line into a new array that match
a particular block device that's being decrypted for inspection. The
function intends to size the result array such that potentially all
\&\fI\-\-key\fR options, plus a terminating \f(CW\*(C`NULL\*(C'\fR element, fit into it. The
code mistakenly uses the \f(CW\*(C`MIN\*(C'\fR macro instead of \f(CW\*(C`MAX\*(C'\fR, and therefore
only one element is allocated before the \f(CW\*(C`NULL\*(C'\fR terminator.
.PP
Passing precisely two \fI\-\-key \s-1ID:...\s0\fR options on the command line for
the encrypted block device \f(CW\*(C`ID\*(C'\fR causes \f(CW\*(C`get_keys\*(C'\fR to overwrite the
terminating \f(CW\*(C`NULL\*(C'\fR, leading to an out-of-bounds read in
\&\f(CW\*(C`decrypt_mountables\*(C'\fR, file \fIlibguestfs\-common/options/decrypt.c\fR.
.PP
Passing more than two \fI\-\-key \s-1ID:...\s0\fR options on the command line for
the encrypted block device \f(CW\*(C`ID\*(C'\fR causes \f(CW\*(C`get_keys\*(C'\fR itself to perform
out-of-bounds writes. The most common symptom is a crash with \f(CW\*(C`SIGSEGV\*(C'\fR
later on.
.PP
This issue affects \*(-- broadly speaking \*(-- all libguestfs-based utilities
that accept \fI\-\-key\fR, namely: \f(CW\*(C`guestfish\*(C'\fR, \f(CW\*(C`guestmount\*(C'\fR, \f(CW\*(C`virt\-cat\*(C'\fR,
\&\f(CW\*(C`virt\-customize\*(C'\fR, \f(CW\*(C`virt\-diff\*(C'\fR, \f(CW\*(C`virt\-edit\*(C'\fR, \f(CW\*(C`virt\-get\-kernel\*(C'\fR,
\&\f(CW\*(C`virt\-inspector\*(C'\fR, \f(CW\*(C`virt\-log\*(C'\fR, \f(CW\*(C`virt\-ls\*(C'\fR, \f(CW\*(C`virt\-sparsify\*(C'\fR,
\&\f(CW\*(C`virt\-sysprep\*(C'\fR, \f(CW\*(C`virt\-tail\*(C'\fR, \f(CW\*(C`virt\-v2v\*(C'\fR.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\fBguestfs\fR\|(3),
\&\fBguestfs\-internals\fR\|(1),
\&\fBguestfs\-release\-notes\fR\|(1),
\&\fBguestfs\-testing\fR\|(1),
http://libguestfs.org/.
.SH "AUTHORS"
.IX Header "AUTHORS"
Richard W.M. Jones (\f(CW\*(C`rjones at redhat dot com\*(C'\fR)
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
Copyright (C) 2009\-2020 Red Hat Inc.
.SH "LICENSE"
.IX Header "LICENSE"
This library is free software; you can redistribute it and/or modify it
under the terms of the \s-1GNU\s0 Lesser General Public License as published
by the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
.PP
This library is distributed in the hope that it will be useful, but
\&\s-1WITHOUT ANY WARRANTY\s0; without even the implied warranty of
\&\s-1MERCHANTABILITY\s0 or \s-1FITNESS FOR A PARTICULAR PURPOSE.\s0  See the \s-1GNU\s0
Lesser General Public License for more details.
.PP
You should have received a copy of the \s-1GNU\s0 Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, \s-1MA
02110\-1301 USA\s0
.SH "BUGS"
.IX Header "BUGS"
To get a list of bugs against libguestfs, use this link:
https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
.PP
To report a new bug against libguestfs, use this link:
https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
.PP
When reporting a bug, please supply:
.IP "\(bu" 4
The version of libguestfs.
.IP "\(bu" 4
Where you got libguestfs (eg. which Linux distro, compiled from source, etc)
.IP "\(bu" 4
Describe the bug accurately and give a way to reproduce it.
.IP "\(bu" 4
Run \fBlibguestfs\-test\-tool\fR\|(1) and paste the \fBcomplete, unedited\fR
output into the bug report.