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 In all three cases, if a GitLab issue is determined to be security relevant, any maintainer could send a request to qemu-security list to get Red Hat product security to allocate a CVE. Out of those I'd probably lean towards (2) which is slightly more restrictive than the kernel new policy but not by much. Some key benefits of using GitLab for security disclosures * We can trivially make disclosures public if we classify them as a non-virtualization use case, or when the fix is ready. * We can formally track the lifecycle of disclosures through to the final fix, for both virtualization & non-virtualization use cases. The only difference will be that the former can request a CVE assignment * We can do reports/queries of outstanding issues * We can more easily use automation to process issues * Maintainers can see bugs without waiting for someone to triage and forward it on their way. * The small number of security bug triage people are no a bottle neck anymore Some downsides/implications * Every disclosure in a confidential issue will be visible to every maintainer who has joined the qemu-project repo on GitLab. IOW that is treating every maintainer as equally trusted. We do have qemu-security though we could be mailed if someone considered their disclosure to be severely impactful but the triage team can't make that decision. * We must NOT grant membership to qemu-project at a Reporter level for anyone whom is not an active maintainer. They must be limited to the "Guest" role at most. * No one is formally responsible for GitLab issue triage. We have had Thomas do it in the past periodically with script assistance. We have Alex doing some of it now with bot assistance. The danger is security disclosures get ignored as "somebody else's problem" no one has accountability. 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 :|
