fixes for stable qemu series

fixes for stable qemu series

[Michael Tokarev]

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?

Thanks,

/mjt

Re: fixes for stable qemu series

[Daniel P. Berrangé]

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.

Those issues should include a link to the mailing list with posted
patches, and also get auto-linked to a merged commit by gitlab.

So if you want to sanity check stable branch content for missing
security fixes, I'd sugest following the CVE::Assigned labels.

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 :|

Re: fixes for stable qemu series

[Peter Maydell]

On Fri, 6 Nov 2026 at 09:22, Daniel P. Berrangé <berrange@redhat.com> 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.

-- PMM

Re: fixes for stable qemu series

[Daniel P. Berrangé]

On Fri, Nov 06, 2026 at 10:17:02AM +0000, Peter Maydell wrote:
> On Fri, 6 Nov 2026 at 09:22, Daniel P. Berrangé <berrange@redhat.com> 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.

Ah ok, and those commits in master pre-dated our new CVE workflow.

In this kind of situation where we miss security implications initially,
if the flaw is considered significant enough, we could potentially
retrospectively request to assign a CVE for an already merged fix.

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 :|

Re: fixes for stable qemu series

[Michael Tokarev]

On 11/6/26 13:17, Peter Maydell wrote:
> On Fri, 6 Nov 2026 at 09:22, Daniel P. Berrangé <berrange@redhat.com> 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.

Thanks,

/mjt

Re: fixes for stable qemu series

[Oleg Drokin]

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é
> > <berrange@redhat.com> 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.