+-- On Thu, 22 Oct 2020, Daniel P. Berrangé wrote --+ | On Thu, Oct 22, 2020 at 12:24:16PM -0400, Alexander Bulekov wrote: | > > Once [2] lands upstream, we should see a significant uptick in oss-fuzz | > > reports, and I hope that we can develop a process to ensure these bugs | > > are properly dealt with. One option we have is to make the reports | > > public immediately and send notifications to qemu-devel. This is the | > > approach taken by some other projects on oss-fuzz, such as LLVM. Though | > > its not on oss-fuzz, bugs found by syzkaller in the kernel, are also | > > automatically sent to a public list. The question is: | > > | > > What approach should we take for dealing with bugs found on oss-fuzz? | | If we assume that a non-negligible number of fuzz bugs will be exploitable | by a malicious guest OS to break out into the host, then I think it is | likely undesirable to make them public immediately without at least a basic | human triage step to catch possibly serious security issues.
* Maybe the proposed 'qemu-security' list can receive such issue reports. It is more close than qemu-devel. But it also depends on the quantum of traffic oss-fuzz generates. We don't want to flood/overwhelm qemu-security list or any other list for that matter. * Human triage is required to know potential impact of an issue before it is sent to a public list. It would not be good to send guest-to-host-escape type issues directly to a public list. * Ideally preliminary human triage should be done on the fuzzers' side. After it hits an issue, someone should have a look at it before sending an email to a list OR maintainer(s). Ex. TCG issues are generally not considered for CVE. They need not go to a security list. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
