Re: [OE-core] [PATCH] improve_kernel_cve_report: use numeric versions instead of cpeApplicability

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2026-04-20 at 07:53 +0000, Daniel Turull via lists.openembedded.org wrote:
> 
> 
> > -----Original Message-----
> > From: Benjamin Robin <benjamin.robin@bootlin.com>
> > Sent: Monday, 20 April 2026 09:30
> > To: openembedded-core@lists.openembedded.org; Daniel Turull
> > <daniel.turull@ericsson.com>
> > Subject: Re: [OE-core] [PATCH] improve_kernel_cve_report: use numeric
> > versions instead of cpeApplicability
> > 
> > On Monday, April 20, 2026 at 9:10 AM, Daniel Turull wrote:
> > > 
> > > > -----Original Message-----
> > > > From: openembedded-core@lists.openembedded.org <openembedded-
> > > > core@lists.openembedded.org> On Behalf Of Benjamin Robin via
> > > > lists.openembedded.org
> > > > Sent: Sunday, 19 April 2026 11:07
> > > > To: openembedded-core@lists.openembedded.org; Daniel Turull
> > > > <daniel.turull@ericsson.com>
> > > > Subject: Re: [OE-core] [PATCH] improve_kernel_cve_report: use
> > > > numeric versions instead of cpeApplicability
> > > > 
> > > > Hello Daniel,
> > > > 
> > > > On Friday, April 17, 2026 at 6:54 PM, Daniel Turull wrote:
> > > > > What I tried to say was that in this case using versions if we
> > > > > have 6.6.100 we
> > > > think we are vulnerable, but the cve was introduced in a backport in
> > 6.6.102.
> > > > Only the range 6.6.102 to 6.6.112 should be vulnerable. I'll see if
> > > > I can report the issues so the source data is correct.
> > > > 
> > > > From the version ranges:
> > > >  -
> > > > 
> > > > The "cpeApplicability" node says:
> > > > 
> > > > {
> > > >     "vulnerable": true,
> > > >     "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
> > > >     "versionStartIncluding": "6.6.102",
> > > >     "versionEndExcluding": "6.6.112"
> > > > },
> > > > 
> > > > So it is very clear that the first vulnerable version starts from
> > > > 6.6.102
> > > > 
> > > > And the "versions" node says:
> > > > 
> > > > {
> > > >     "version": "6.6.112",
> > > >     "lessThanOrEqual": "6.6.*",
> > > >     "status": "unaffected",
> > > >     "versionType": "semver"
> > > > },
> > > > 
> > > > Which is coherent, version 6.6.112 is not vulnerable.
> > > > 
> > > > So in summary we are having:
> > > >  - [>=6.6.0, <6.6.102] => not vulnerable,
> > > >  - [>=6.6.102, <6.6.112] => vulnerable,
> > > >  - [>=6.6.112, <=6.6.*] => not vulnerable.
> > > > 
> > > > To have a full picture, we must use all the information
> > > > ("cpeApplicability" and "versions" nodes).
> > > > But now I am starting to understand what you are saying :)
> > > > 
> > > > > in this case using versions if we have 6.6.100 we think we are
> > > > > vulnerable
> > > > 
> > > > If we are only looking at the "versions" node, we may think that any
> > > > version below 6.6.102 is vulnerable (e.g., the 6.6.100 version).
> > > 
> > > Exactly.
> > > 
> > > > 
> > > > This is not the only CVE that is like that; a *lot* of kernel CVEs are in this
> > case.
> > > > So I don't know why Greg Kroah-Hartma said that cpeApplicability
> > > > nodes should not be used. Without it, the full picture of which
> > > > version is vulnerable cannot be obtained.
> > > 
> > > I think is because if you look literally the versions without looking
> > > like a tree (which we do) the information is not correct. For example,
> > > imagine that the correction is 6.6.100, then any 6.7.X is not affected, but that
> > 6.6.100 was a backport and it was never backported to 6.7.X since it is not
> > supported anymore.
> > 
> > Yes I understand that, but why we should not look it like a tree? sbom-cve-
> > check in main branch has a special case for the kernel which do a specific
> > processing for all these version ranges provided by the kernel CNA.
> 
> I'm not saying that we should not look that a tree. We are doing the correct thing. Only if you take the 
> naive approach and compare versions 6.6.100 < 6.7.1, even 6.6.100 has a fix and 6.7.1 not.
> 
> > > > > If we plan to drop the script, I should probably not spend too
> > > > > much time on
> > > > the script itself but on the data quality.
> > > > 
> > > > I don't know if we are going to drop the script.
> > > > Previously the script had some flows (and it still has), and since
> > > > sbom-cve- check (in the next release) should do better, I was going
> > > > to propose its suppression (In a few weeks).
> > > 
> > > Can you point to the flaws, so I'm aware?
> > 
> > The current version of improve_kernel_cve_report.py does not process the
> > "versions" nodes. We need both sources of information.
> > 
> > I did not double check if these findings are right (but at first glance it looked
> > wrong):
> >  - If at least one entry does not have versionStartIncluding defined,
> >    first_affected is going to be 0.
> >  - It does not handle versionStartExcluding
> >  - It does not handle the fact that we could have multiples ranges
> >    within the same branch that is vulnerable.
> >  - Maybe there are others issues, I did not spent to much time analyzing
> >    it since I choose to use a different way to do that.
> 
> Thanks, I need to look at start using sbom-cve-check. It is true, there are a few corner cases.

Did we reach a consensus on what we should do with this patch?

We (as in patch review/triage) couldn't quite understand what the end result was!

Cheers,

Richard