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@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