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

Benjamin Robin
2026-04-20T07:30:18Z

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