The recent CVE-2022-0485 demonstrated that clients that pass in an
uninitialized buffer to nbd_pread and friends, but are then not
careful about checking for read errors, were subjected to
server-dependent behavior on whether their use of the buffer after
failure saw sanitized zeroes or prior heap
In documenting the recent CVE-2022-0485 bug in nbdcopy, I pointed out
that the severity of the flaw was server-dependent (a server with
structured replies caused nbdcopy to write zeroes, but a server
without structured replies caused nbdcopy to leak heap contents). In
fact, this series demonstrate
The recent patch series for CVE-2022-0485 demonstrated that when
applications using libnbd are not careful about error checking, the
difference on whether a data leak is at least sanitized (all zeroes,
partial reads, or data leftover from a prior read) vs. a dangerous
information leak (uninitialize
As mentioned in the previous patch, we left the state of the buffer
undefined if we fail pread prior to attempting NBD_CMD_READ. Better
is to tweak the generator to sanitize the buffer unconditionally, as a
way of hardening against potential bugs in client applications that
fail to check for error
On Wed, Feb 09, 2022 at 03:51:24PM +0200, Nir Soffer wrote:
> On Wed, Feb 9, 2022 at 12:32 PM Richard W.M. Jones wrote:
> > + (* We must kill all our nbdkit instances before finalizing the
> > + * transfer. See:
> > + *
> > https://listman.redhat.com/archives/libguestfs/2022-February/msg001
On Wed, Feb 9, 2022 at 12:32 PM Richard W.M. Jones wrote:
>
> If nbdkit instance(s) are still running then they will hold open some
> http connections to imageio. In some versions of imageio, starting
> finalization in this state causes a 60 second timeout.
>
> See-also:
> https://listman.redhat
On Wed, Feb 09, 2022 at 02:17:38PM +0100, Laszlo Ersek wrote:
> Utilities shouldn't directly call "Std_utils.wrap" for printing
> informative messages; the "Tools_utils.info" function handles that better.
>
> Because "info" prints a trailing newline automatically, strip one newline
> from the orig
On 02/09/22 11:32, Richard W.M. Jones wrote:
> If nbdkit instance(s) are still running then they will hold open some
> http connections to imageio. In some versions of imageio, starting
> finalization in this state causes a 60 second timeout.
>
> See-also:
> https://listman.redhat.com/archives/l
Utilities shouldn't directly call "Std_utils.wrap" for printing
informative messages; the "Tools_utils.info" function handles that better.
Because "info" prints a trailing newline automatically, strip one newline
from the originally wrapped messages. While at it, rewrap (in the source
code) the "R
Hi Nir,
With my version 2 patch, it now takes about the same time to do a
conversion as it did with old virt-v2v.
However one thing I noticed is that we lose about 16 seconds between
creating the disk and creating the transfer. Notice the timestamps
here:
00:00:41 python3 '/tmp/v2v.fvLq7Z/rhv
This addresses points raised in Laszlo's review:
https://listman.redhat.com/archives/libguestfs/2022-February/msg00127.html
___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
If nbdkit instance(s) are still running then they will hold open some
http connections to imageio. In some versions of imageio, starting
finalization in this state causes a 60 second timeout.
See-also:
https://listman.redhat.com/archives/libguestfs/2022-February/msg00111.html
Thanks: Nir Soffer
On 02/08/22 16:07, Richard W.M. Jones wrote:
> If nbdkit instance(s) are still running then they will hold open some
> http connections to imageio. In some versions of imageio, starting
> finalization in this state causes a 60 second timeout.
>
> See-also:
> https://listman.redhat.com/archives/l
13 matches
Mail list logo
