On Fri, 2026-11-06 at 15:26 +0300, Michael Tokarev wrote:
> On 11/6/26 13:17, Peter Maydell wrote:
> > On Fri, 6 Nov 2026 at 09:22, Daniel P. Berrangé
> > <[email protected]> wrote:
> > >
> > > On Fri, Nov 06, 2026 at 12:15:06PM +0300, Michael Tokarev wrote:
> > > > Hi!
> > > >
> > > > What's the way you use to find these patches, with security
> > > > impact or not?
> > > >
> > > > I usually quickly screen all new commits in the master branch,
> > > > and often
> > > > catch things which aren't marked for-stable, - not everything
> > > > of interest
> > > > is marked as such. I also tend to remind the maintainers about
> > > > these
> > > > markings. But my resources here are limited, I can't try to
> > > > understand
> > > > every patch, even description of it.
> > > >
> > > > How do you perform a security review?
> > >
> > > FWIW, with our new security triage process, we should be fairly
> > > reliably getting issues in gitlab tagged with CVE::Assigned, if
> > > they have been accepted as an in-scope security issue and had a
> > > CVE assigned.
> >
> > I think in this case we're talking about #4802 (confidential),
> > and the problem is that the commits in question were not given
> > a CVE or tagged for stable, because it wasn't realised at the time
> > that they were fixing a bug.
> Not really. I understand this one weren't considered an issue at
> the time of patching, - only now it come as a serious vuln.
>
> I'm talking about what Daniel mentioned above, exactly. Plus how
> Oleg were finding the issues/fixes, including this #4802 too.
I am afraid I am one of those stereotypical "drive-by genai" users in
this case. I have a toy hobby project of migrating a particularly
security-conscious project that I use from xen to kvm because of xen
shortcomings for my usecase ("scratch your own itch" scope lately
became quite expanded thanks to the new tooling availability) and as
part of that I instructed the agent to perform a security review and
compare surfaces to xen and it came up with a number of findings in
qemu and kernel and elsewhere (which is not atypical today, we have
quite a bit of a problem with that in Lustre (that I am one of the
maintainers of), you are just working on something and then do an ai-
assisted codereview and suddenly it highlights a bunch of adjacent
problems that are security related). And then the next step is to just
tell the same (or another) agent to see if there are known fixes for
these problems and if not - to develop a proof of concept to
demonstrate the problem is actually real (because hallucinations still
run wild everywhere).
So when generating the follow on list it just became a "scan everything
else in master that's not in 10.0.x that we want to carry" and it
checked all 14300 or so commits since 10.0 evaluated them and came up
with the list. This does not make me a qemu expert obviously and I
fully realize that but the list does look real.
Once my toy thing progresses far enough I also plan to do a "you are
here in this vm, try to escape" test and I hope it fails ;)
I guess it is a mostly one-time thing to cover the gaps of the past (I
rerun ai-assisted code on 4 years of historical Lustre commits in a
similar fashion and it was very valuable) and going forward there are
processes in place already to cover all this current stuff better and
consistently (like what Daniel was talking about).
The other thing is Anthropic has some sort of an OSS scanner/fixer they
run in-house that you can apply for and they work their magic to find
real deep defects and even submit fixes (apparently qemu is not keen on
ai-generated contributions so may be that's off limits for you) and you
might find at least some of that useful.
