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

[Benjamin Robin <benjamin.robin@bootlin.com>]

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.

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

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com