[Libguestfs] [nbdkit PATCH v2] blocksize: Avoid losing aligned writes to RMW race

[Eric Blake]

On Fri, May 27, 2022 at 11:06:23AM -0500, Eric Blake wrote:
> On Fri, May 27, 2022 at 11:19:24AM +0100, Richard W.M. Jones wrote:
> > On Thu, May 26, 2022 at 04:00:08PM -0500, Eric Blake wrote:
> > > [We are still investigating if a CVE needs to be assigned.]
> > > 
> > 
> > Reviewed-by: Richard W.M. Jones <rjones at redhat.com>
> > 
> > I have no preference on whether or not to put the test into a
> > separate commit.
> > 
> > I'm not sure I understand where the potential CVE is.  In what
> > scenario could the old filter be exploited?
> 
> I'm still struggling on whether the data corruption can be turned into
> a privilege escalation.  Someone using nbdkit to prepare disk images
> does not expect the data to be corrupted, but they are also unlikely
> to be using overlapping writes.  A guest using overlapping writes
> should already be expecting non-deterministic behavior, so whether
> that behavior also acts like ignoring writes to the non-overlapping
> portion is hard to justify as an escalation avenue.  It might be that
> the data corruption caused by wrong contents to part of a block could
> lead to followon exploits of a bug in file-system code, but it also
> seems hard to argue that you can target such a race intentionally.  A
> MitM attacker could inject parallel writes - but they can already do
> so much more that you already should be relying on TLS.
> 
> So it may be that there is no CVE - but I at least wanted to get the
> thought process out there.  I've reached out to Red Hat secalert to
> see if we can get a second opinion from someone that is more familiar
> with which sorts of data corruption can be turned into exploits.
> 
> I'll wait to push this commit (well, split into two, per Laszlo's
> request) for a few days, to see if secalert wants to chime in.

secalert hasn't chimed in, so even if it does get a CVE down the road,
it is obviously low priority.  I've now split this (fix vs. test
addition, rebase to work with libnbd h.pread producing bytearray), and
pushed as:

1dbf3fcd..baa63f05

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org