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(a)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.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org