Re: [PATCH v2 1/3] docs: Mention security considerations for NBD

[Eric Blake <eblake@redhat.com>]

On Mon, Nov 09, 2026 at 08:58:47AM -0700, Stefan Hajnoczi wrote:
> On Sat, Nov 07, 2026 at 04:54:36PM -0600, Eric Blake wrote:
> > +Proper hardening of network connections can prevent the use of
> > +untrusted clients, and is therefore a factor when considering whether
> > +a malicious network partner that intentionally violates the
> > +communication protocol to trigger a QEMU bug can be treated as a lower
> > +priority bug.
> 
> IMO there is no such thing as a trusted client - QEMU needs to validate
> all inputs. When a client is authorized to use a resource (e.g. an NBD
> export) it can still be rogue and trigger a Denial of Service that
> affects the guest or other clients.

> 
> Did you add this because there was no CVE assigned yet? Maybe you can
> remove this since a CVE has been assigned?

I've got at least one other bug pending that I'm about to lift
confidentiality on, in the same boat where TLS prevents untrusted
client behavior, but where I don't have a CVE number yet. But I agree
that since we don't fully control even a trusted client process, ANY
flaw in the client that allows the client to start sending
non-compliant data over the wire can then be escalated further into an
attack on QEMU, despite QEMU minimizing the risk of such attacks by
first filtering out obvious untrusted clients.

I'm trying to figure out the best balance of wording for that. In the
CVSS scoring system [1], you are arguing (and I agree) that the CVSS-B
base score is unchanged by whether or not TLS was in use (we don't
control the remote client; if the remote client can send non-compliant
bytes over the wire, QEMU will assert). However, the environmental
metrics of CVSS-BE cover Attack Complexity (AC) and Attack
Requirements (AR) that consider how hard it is to get the client to be
non-compliant in the first place.  Once attack chaining is involved,
the risk to QEMU is less than if the attacker does not first have to
compromise a trusted client into sending non-compliant bytes.

[1] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

Maybe the solution is as simple as rewording "trusted client" into
"authenticated client", to emphasize that while any client misbehavior
that can crash QEMU is still likely to be a CVE, the authentication
aspect affects the Environmental analysis which in turn reduces the
overall CVSS-BE rating of the attack.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org