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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Nov 09, 2026 at 02:48:18PM -0600, Eric Blake wrote:
> 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.

Yes, using 'authenticated client' is a better term, as that is more
of a clear "fact", where as "trusted client" can mean many different
things in different people & scenarios

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|