On Thu, May 21, 2026 at 1:14 AM Michael S. Tsirkin <[email protected]> wrote: > > On Wed, May 20, 2026 at 06:39:14PM +0100, Daniel P. Berrangé wrote: > > On Wed, May 20, 2026 at 12:33:16PM -0500, Pierrick Bouvier wrote: > > > On 5/20/2026 10:09 AM, Daniel P. Berrangé wrote: > > > > On Wed, May 20, 2026 at 10:01:14AM -0500, Pierrick Bouvier wrote: > > > >> Hi Daniel, > > > >> > > > >> On 5/19/2026 9:26 AM, Daniel P. Berrangé wrote: > > > >>> The qemu-security mailing list was created several years back now and > > > >>> traditionally saw 1-2 disclosures a month at worst. This was > > > >>> manageable. > > > >>> > > > >>> Since approx March 1st, the new normal is to see as many as 20 > > > >>> disclosures > > > >>> in one single day, more than 200 in total now. This is unsustainable. > > > >>> I was thinking we needed more people on qemu-security to triage, but > > > >>> IMHO > > > >>> this won't really fix the problem. > > > >>> > > > >> > > > >> Considering the increase in number of issues, would that be possible to > > > >> make stricter rules about what is expected? > > > >> > > > >> For instance, asking for a working exploit and optionally a VM image + > > > >> instructions to reproduce it. I am not expert on the topic, but what I > > > >> see is that if we have this, all duplicates would be eliminated at > > > >> once. > > > > > > > > With the new crop of AI assisted disclosures there is absolutely no > > > > lack of data provided. > > > > > > > > Most come with reproducible exploits, detailed descriptions and > > > > analysis, > > > > and more - everything you could conceivably need to triage the > > > > disclosure. > > > > Reading and interpreting this takes significant mental effort and > > > > there's > > > > too much data to quickly/easily eliminate dupes. > > > > > > > > > > Maybe we need to "standardize" this part then. > > > Or do something like asking a (GitLab) CI pipeline to be written to > > > expose the issue. If we can just run this with a specific qemu > > > remote/branch, it becomes trivial to rerun it when fixes are pushed. > > > > > > It definitely does not solve the original scaling issue, but maybe can > > > help to absorb it, and spend time where it's useful: writing and > > > upstreaming a fix, and check it "broke" the exploit. > > > > > > >>> This needs an issue tracker to cope with & email is not an issue > > > >>> tracker. > > > >>> We faked an issue tracker with a shared spreadsheet to prevent us > > > >>> drowning > > > >>> these past few months, but this is still not sustainable & probably > > > >>> won't > > > >>> ever be. > > > >>> > > > >> > > > >> Overall, you're right. > > > >> However, changing the tool won't solve the number of issues sent, and > > > >> for that, something additional is needed. > > > > > > > > I don't expect there to be any change in submission rate. The proposal > > > > is based on the expectation that the submission rate will continue at > > > > a high level for a long time. Primarily the goal is to reduce the > > > > tracking and triage work overhead and to eliminate/reduce single person > > > > bottlenecks in the process > > > > > > > >> I wonder also what is the percentage of duplicates there is from what > > > >> you observed in the last 2 months. Any rough idea of the number? > > > > > > > > Definitely at least 10%, probably closer to 15%. > > > > > > > > > > Ok, interesting number, thanks. I was expecting much more, but I'm > > > biased having heard Linus this morning talk about this for Linux kernel. > > > > I expect the dupes to increase over time as more people run the > > same analysis across QEMU, especially given that most of the bugs > > are not yet fixed. > > > > 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 :| > > > something I was unaware of previously, is that gitlab is a CNA: > https://about.gitlab.com/security/cve/ > > so using gitlab issues means assigning CVE #s should be super easy.
Red Hat is a CNA too, QEMU CVEs are currently being reserved by Red Hat. In fact, Red Hat is a root CNA: https://www.cve.org/Media/News/item/blog/2023/01/10/Why-Red-Hat-Became-Root Projects like glibc, postgresql and curl now operate as independent CNAs under Red Hat, retaining complete end-to-end ownership over CVE assignment. Is it time for QEMU to follow suit? > -- > MST > -- Mauro Matteo Cascella Red Hat Product Security PGP-Key ID: BB3410B0
