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. This would force security researchers to spend time (and tokens) on providing a concrete test and environment to reproduce, which really helps with fixing and testing. Else, simply ignore and close those issues. > 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 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? > 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 Regards, Pierrick
