[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE-2020-16092 QEMU: reachable assertion failure in net_tx_pkt_add_raw_fragment()
From:       Mauro Matteo Cascella <mcascell () redhat ! com>
Date:       2020-08-10 9:57:02
Message-ID: CAA8xKjXJ7DjJ7jAfR6hrbUOOfi7p8sCZSSdt9Hs7bj=Ez03eWA () mail ! gmail ! com
[Download RAW message or body]

Hi Michael,

On Mon, Aug 10, 2020 at 11:23 AM Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> Hmm. Is it really worth the effort to treat these things as security
> issues? There are so many ways to crash a machine (be it virtual or
> hardware), there are definitely countless ways to crash things from
> within privileged code.. what's the security impact of a hardware
> issue when, say, a driver code in the OS does a stupid thing and
> the hardware locks up?
>

I see your point. Our general assumption is to *not* consider assert()
failures CVE worthy if they can only be triggered by privileged users
[1]. In this case specifically, given the assertion failure occurs
while sending packets from the guest, we assumed it may be possible
for an unprivileged guest user to cause a DoS scenario (e.g., by
sending malicious/malformed network packets). In accordance with QEMU
maintainers, we therefore decided to provide a fix for this bug. But
again, I agree these kinds of issues tend to be questionable, so we
typically proceed on a case-by-case basis.

[1] https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg03869.html

Thanks,

-- 
Mauro Matteo Cascella, Red Hat Product Security
6F78 E20B 5935 928C F0A8  1A9D 4E55 23B8 BB34 10B0

[prev in list] [next in list] [prev in thread] [next in thread]