On Tue, May 19, 2026 at 11:18:31AM -0400, Michael S. Tsirkin wrote: > On Tue, May 19, 2026 at 03:26:51PM +0100, 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. > > > > 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. > > > > The traditional POV was that security disclosures must be dealt with on > > a strict "need to know" basis until there was a concious decision to make > > them public. Typically that happened when a patch was published by the > > maintainer on qemu-devel. Rarely have we applied an embargo period after > > a maintainer had a patch ready to post, as most bugs were not severe > > enough. Also in typical usage Libvirt has SELinux/AppArmour to mitigate > > impact of a guest ecsape into QEMU. > > > > QEMU is not alone in this chaos, to quote Linus > > > > https://lkml.org/lkml/2026/5/17/896 > > > > [quote] > > the continued flood of AI reports has basically made the security list > > almost entirely unmanageable, with enormous duplication due to > > different people finding the same things with the same tools. People > > spend all their time just forwarding things to the right people or > > saying "that was already fixed a week/month ago" and pointing to the > > public discussion. > > [/quote] > > > > They have explicitly changed their policy for disclosure now: > > > > > > https://github.com/torvalds/linux/commit/a03ef333fbd6cd861c8457c3d055ee3643a9baad > > > > [quote] > > If you resorted to AI assistance to identify a bug, you must treat > > it as public. While you may have valid reasons to believe it is not, > > the security team's experience shows that bugs discovered this way > > systematically surface simultaneously across multiple researchers, > > often on the same day > > [/quote] > > > > IME for qemu-security we've definitely seen the same bugs reported by > > different people, within days of each other, a couple of times even > > the same day. Dupes are not the majority - QEMU has so much low > > hanging fruit - but they're a sizeable chunk. > > > > > > Because we don't have a good automated way to publish disclosures > > from qemu-security, we don't provide contributors any way to check > > for duplicates before submission. The burden of checking for dupes > > thus falls on the qemu-security triage people, or the maintainers > > we forward issues to. > > > > For disclosures in the non-virtualization use case, we ask the > > reporter to file a gitlab issue or send a patch. They almost never > > do this. We're lucky to have any reply to emails at all. > > > > > > IMHO we need to move to an issue tracker. GitLab was originally > > discounted in favour of qemu-security list since "Confidential" > > issues cannot have visibility managed in a fine grained way. > > They are visible to everyone with "Reporter" role or higher, > > which is 70+ people for QEMU. > > > > If we accept the kernel's view that AI discovered issues should be > > considered public immediately because of the high chance of parallel > > "discovery", then GitLab's limitations don't seem to bad. > > > > It is also of note that we've had some people ignoring qemu-security > > policy and directly filing public gitlab issues for stuff discovered > > via AI/LLM agents already. Those are not getting attention for CVE > > assignment, should it be needed which and can't be cross-referenced > > by general maintaniers to stuff we have received via qemu-security. > > > > We have some options IMHO > > > > 1. Move all security disclosure to GitLab confidential issues > > no disclosures via email > > > > 2. Move AI/fuzzer assisted disclosures to GitLab confidential > > issues, keep human discovered issues on qemu-security list > > > > 3. Move AI/fuzzer assisted disclosures to GitLab public > > issues, keep human discovered issues on qemu-security list > > or 4. do it like linux did, and move ai assisted disclosured > to the public ML. Fuzzer assisted can stay with human discovered.
Linux could do that because of the way they issue CVEs. IIUC, every bug that goes into stable kernels gets evaluated for whether a CVE is required. Thus they don't need to do CVE allocation in alignment with any bug disclosure process. While our stable branch process for QEMU is healthier than it has ever been, it is still essentially a 1 person effort looking for candidate patches, not a strong enough culture of maintainers sending patches to stable proactively. So I don't think we're in a position to replicate Linux's approach to CVE assignment. So IMHO we still need to have some issue tracking mechanism to tag incoming disclosures as needing CVE assignment or not. If all disclosures end up on qemu-devel and untracked we'll just never end up getting CVEs for most of them. That doesn't feel like a viable approach 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 :|
