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

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

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:
 - https://cveawg.mitre.org/api/cve/CVE-2025-40067
 - https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2025/CVE-2025-40067.json

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).

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.

> 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).

> Have a nice weekend
> Daniel
> 
> ________________________________
> From: Benjamin Robin <benjamin.robin@bootlin.com>
> Sent: Friday, April 17, 2026 4:47 PM
> To: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>; Daniel Turull <daniel.turull@ericsson.com>
> Subject: Re: [PATCH] improve_kernel_cve_report: use numeric versions instead of cpeApplicability
> 
> On Friday, April 17, 2026 at 4:35 PM, Daniel Turull wrote:
> > True,
> > I sent CVEs that had different responses. I used an old checkout and rerun with the old and the new script.
> >
> > I'm starting to find some issues with the data that we should clarify before merging this patch. Let's pause it and have it correct.
> >
> > For example,
> >
> > "defaultStatus": "affected",
> > {
> >                      "version": "6.6.112",
> >                      "lessThanOrEqual": "6.6.*",
> >                      "status": "unaffected",
> >                      "versionType": "semver"
> >                   },
> >
> > "negate": false,
> > {
> >                            "vulnerable": true,
> >                            "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
> >                            "versionStartIncluding": "6.6.102",
> >                            "versionEndExcluding": "6.6.112"
> >                         },
> 
> I see nothing wrong here.
> In [>6.6.102, <6.6.112] => vulnerable, and [>=6.6.112, <=6.6.*] => not vulnerable.
> 
> > In this case, the information in one of the entries is not correct. For example, in 6.6.100 is vulnerable in the version not in the cpeApplicability, but git versions and cpeApplicability match if we do a git describe on them.
> 
> I really did not understood this sentence.
> Be aware that if you do a git describe, this is the tag that can be reached
> that is displayed, not the tag that include the commit!
> 
> Could you elaborate in more details, I may be wrong here...

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