| Message ID | 20260417132409.1638132-1-daniel.turull@ericsson.com |
|---|---|
| State | Under Review |
| Headers | show |
| Series | improve_kernel_cve_report: use numeric versions instead of cpeApplicability | expand |
Hello Daniel, On Friday, April 17, 2026 at 3:24 PM, daniel.turull@ericsson.com wrote: > From: Daniel Turull <daniel.turull@ericsson.com> > > git shas or versions should be use instead of cpeApplicability. > Reuse the same logic as generate-cve-exclusions, so outputs are consistent. > > cpeApplicability does not provide accurate version information and for some > CVEs the information is not the same. This came from a discussion that > we had with Greg Kroah-Hartma, member of the Linux security team. Indeed "cpeApplicability" does not provide the same kind of information that the "versions" node. In sbom-cve-check (the latest version in main branch) we are using both sources of information. But you are saying that "cpeApplicability" does not provide accurate version information. Could you elaborate and give various examples? I never saw something invalid in "cpeApplicability". > Signed-off-by: Daniel Turull <daniel.turull@ericsson.com> > --- > scripts/contrib/improve_kernel_cve_report.py | 247 ++++++++----------- > 1 file changed, 104 insertions(+), 143 deletions(-)
Hi,
We had Greg visiting us and I asked him what is better to use and he said git or versions, not cvepAplicability that has issues defining trees.
I have done some comparison with 6.6.100 and 6.18.22
=== 6.6.100 ===
Old: 10900 New: 10898 Match: 10418 Only old: 2 Only new: 0 Diff: 480
327 Unpatched/version-in-range -> Unpatched/version-in-range
106 Patched/fixed-version -> Patched/fixed-version
16 Patched/cpe-stable-backport -> Unpatched/version-in-range
15 Unpatched/version-in-range -> Patched/fixed-version
5 Patched/fixed-version -> Unpatched/known-affected
5 Patched/fixed-version -> Unpatched/version-in-range
2 Patched/cpe-stable-backport -> Patched/fixed-version
1 Patched/version-not-in-range -> Unpatched/version-in-range
1 Patched/cpe-stable-backport -> Unpatched/known-affected
1 Patched/version-not-in-range -> Patched/fixed-version
1 Unpatched/version-in-range -> Unpatched/known-affected
Only in old:
CVE-2024-0000: Patched/version-not-in-range
CVE-2024-0053: Patched/version-not-in-range
=== 6.18.22 ===
Old: 10900 New: 10898 Match: 10877 Only old: 2 Only new: 0 Diff: 21
7 Unpatched/version-in-range -> Unpatched/version-in-range
6 Patched/fixed-version -> Patched/fixed-version
6 Patched/fixed-version -> Unpatched/known-affected
1 Unpatched/version-in-range -> Unpatched/known-affected
1 Unpatched/version-in-range -> Patched/cpe-stable-backport
Only in old:
CVE-2024-0000: Patched/version-not-in-range
CVE-2024-0053: Patched/version-not-in-range
old vs new outputs for kernel 6.18.22
Old total: 10900
New total: 10898
Matching: 10877
Only in old: 2
Only in new: 0
Different: 21
Difference categories:
7 Unpatched/version-in-range -> Unpatched/version-in-range
6 Patched/fixed-version -> Patched/fixed-version
6 Patched/fixed-version -> Unpatched/known-affected
1 Unpatched/version-in-range -> Unpatched/known-affected
1 Unpatched/version-in-range -> Patched/cpe-stable-backport
Only in old (2):
CVE-2024-0000: Patched/version-not-in-range: No CPE match
CVE-2024-0053: Patched/version-not-in-range: No CPE match
Different (all 21):
CVE-2021-47295:
old: Patched/fixed-version: Fixed from version 6.2.5
new: Patched/fixed-version: Fixed from version 5.14
CVE-2021-47342:
old: Patched/fixed-version: Fixed from version 5.12.5000
new: Patched/fixed-version: Fixed from version 5.10.77
CVE-2022-50396:
old: Patched/fixed-version: Fixed from version 6.2.5
new: Patched/fixed-version: Fixed from version 6.2
CVE-2023-53012:
old: Patched/fixed-version: Fixed from version 6.1.5000
new: Unpatched/known-affected: No known resolution
CVE-2023-53187:
old: Patched/fixed-version: Fixed from version 5.15.5000
new: Unpatched/known-affected: No known resolution
CVE-2024-49854:
old: Patched/fixed-version: Fixed from version 5.10.5000
new: Unpatched/known-affected: No known resolution
CVE-2025-38656:
old: Patched/fixed-version: Fixed from version 6.12.5000
new: Unpatched/known-affected: No known resolution
CVE-2025-68195:
old: Patched/fixed-version: Fixed from version 6.12.5000
new: Unpatched/known-affected: No known resolution
CVE-2025-68357:
old: Patched/fixed-version: Fixed from version 6.17.5000
new: Patched/fixed-version: Fixed from version 6.12.64
CVE-2025-71145:
old: Patched/fixed-version: Fixed from version 5.10.5000
new: Unpatched/known-affected: No known resolution
CVE-2026-23288:
old: Patched/fixed-version: only affects 6.19.4 onwards
new: Patched/fixed-version: only affects 6.19 onwards
CVE-2026-23327:
old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc2)
CVE-2026-23328:
old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
CVE-2026-23333:
old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.4)
new: Unpatched/known-affected: No known resolution
CVE-2026-23341:
old: Patched/fixed-version: only affects 6.19.4 onwards
new: Patched/fixed-version: only affects 6.19 onwards
CVE-2026-23355:
old: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
new: Patched/cpe-stable-backport: Backported in 6.18.18
CVE-2026-23371:
old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
CVE-2026-23374:
old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
CVE-2026-23377:
old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
CVE-2026-23389:
old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
CVE-2026-23394:
old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.10)
new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc5)
Best regards,
Daniel
> -----Original Message-----
> From: Benjamin Robin <benjamin.robin@bootlin.com>
> Sent: Friday, 17 April 2026 15:32
> To: openembedded-core@lists.openembedded.org; Daniel Turull
> <daniel.turull@ericsson.com>
> Subject: Re: [PATCH] improve_kernel_cve_report: use numeric versions
> instead of cpeApplicability
>
> [You don't often get email from benjamin.robin@bootlin.com. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello Daniel,
>
> On Friday, April 17, 2026 at 3:24 PM, daniel.turull@ericsson.com wrote:
> > From: Daniel Turull <daniel.turull@ericsson.com>
> >
> > git shas or versions should be use instead of cpeApplicability.
> > Reuse the same logic as generate-cve-exclusions, so outputs are consistent.
> >
> > cpeApplicability does not provide accurate version information and for
> > some CVEs the information is not the same. This came from a
> > discussion that we had with Greg Kroah-Hartma, member of the Linux
> security team.
>
> Indeed "cpeApplicability" does not provide the same kind of information that
> the "versions" node.
> In sbom-cve-check (the latest version in main branch) we are using both
> sources of information.
> But you are saying that "cpeApplicability" does not provide accurate version
> information. Could you elaborate and give various examples? I never saw
> something invalid in "cpeApplicability".
>
> > Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
> > ---
> > scripts/contrib/improve_kernel_cve_report.py | 247
> > ++++++++-----------
> > 1 file changed, 104 insertions(+), 143 deletions(-)
>
>
> --
> Benjamin Robin, Bootlin
> Embedded Linux and Kernel engineering
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbootlin
> .com%2F&data=05%7C02%7Cdaniel.turull%40ericsson.com%7C3ca7f33551f2
> 46de878808de9c85c084%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
> %7C639120295445918854%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=F%2F5gD%2FMGt0tXSMT1fZ9yh6%2
> BJJN3tn%2BqOCJ%2F2TchpDO4%3D&reserved=0
>
>
On Friday, April 17, 2026 at 3:44 PM, Daniel Turull wrote: > Hi, > We had Greg visiting us and I asked him what is better to use and he said git or versions, not cvepAplicability that has issues defining trees. You reply is technically not responding to my question :) Could you provide at least one example with an entry that is not correct in the cpeApplicability node? The script had previously various issue (or at least it looked like it). I preferred to use a completely different algorithm (and using all sources of information) But since I am also using NVD entries this degrade a bit the quality of the generated assessment message > I have done some comparison with 6.6.100 and 6.18.22 > > > === 6.6.100 === > Old: 10900 New: 10898 Match: 10418 Only old: 2 Only new: 0 Diff: 480 > 327 Unpatched/version-in-range -> Unpatched/version-in-range > 106 Patched/fixed-version -> Patched/fixed-version > 16 Patched/cpe-stable-backport -> Unpatched/version-in-range > 15 Unpatched/version-in-range -> Patched/fixed-version > 5 Patched/fixed-version -> Unpatched/known-affected > 5 Patched/fixed-version -> Unpatched/version-in-range > 2 Patched/cpe-stable-backport -> Patched/fixed-version > 1 Patched/version-not-in-range -> Unpatched/version-in-range > 1 Patched/cpe-stable-backport -> Unpatched/known-affected > 1 Patched/version-not-in-range -> Patched/fixed-version > 1 Unpatched/version-in-range -> Unpatched/known-affected > Only in old: > CVE-2024-0000: Patched/version-not-in-range > CVE-2024-0053: Patched/version-not-in-range > > === 6.18.22 === > Old: 10900 New: 10898 Match: 10877 Only old: 2 Only new: 0 Diff: 21 > 7 Unpatched/version-in-range -> Unpatched/version-in-range > 6 Patched/fixed-version -> Patched/fixed-version > 6 Patched/fixed-version -> Unpatched/known-affected > 1 Unpatched/version-in-range -> Unpatched/known-affected > 1 Unpatched/version-in-range -> Patched/cpe-stable-backport > Only in old: > CVE-2024-0000: Patched/version-not-in-range > CVE-2024-0053: Patched/version-not-in-range > > old vs new outputs for kernel 6.18.22 > > Old total: 10900 > New total: 10898 > Matching: 10877 > Only in old: 2 > Only in new: 0 > Different: 21 > > Difference categories: > 7 Unpatched/version-in-range -> Unpatched/version-in-range > 6 Patched/fixed-version -> Patched/fixed-version > 6 Patched/fixed-version -> Unpatched/known-affected > 1 Unpatched/version-in-range -> Unpatched/known-affected > 1 Unpatched/version-in-range -> Patched/cpe-stable-backport > > Only in old (2): > CVE-2024-0000: Patched/version-not-in-range: No CPE match > CVE-2024-0053: Patched/version-not-in-range: No CPE match > > Different (all 21): > CVE-2021-47295: > old: Patched/fixed-version: Fixed from version 6.2.5 > new: Patched/fixed-version: Fixed from version 5.14 > CVE-2021-47342: > old: Patched/fixed-version: Fixed from version 5.12.5000 > new: Patched/fixed-version: Fixed from version 5.10.77 > CVE-2022-50396: > old: Patched/fixed-version: Fixed from version 6.2.5 > new: Patched/fixed-version: Fixed from version 6.2 > CVE-2023-53012: > old: Patched/fixed-version: Fixed from version 6.1.5000 > new: Unpatched/known-affected: No known resolution > CVE-2023-53187: > old: Patched/fixed-version: Fixed from version 5.15.5000 > new: Unpatched/known-affected: No known resolution > CVE-2024-49854: > old: Patched/fixed-version: Fixed from version 5.10.5000 > new: Unpatched/known-affected: No known resolution > CVE-2025-38656: > old: Patched/fixed-version: Fixed from version 6.12.5000 > new: Unpatched/known-affected: No known resolution > CVE-2025-68195: > old: Patched/fixed-version: Fixed from version 6.12.5000 > new: Unpatched/known-affected: No known resolution > CVE-2025-68357: > old: Patched/fixed-version: Fixed from version 6.17.5000 > new: Patched/fixed-version: Fixed from version 6.12.64 > CVE-2025-71145: > old: Patched/fixed-version: Fixed from version 5.10.5000 > new: Unpatched/known-affected: No known resolution > CVE-2026-23288: > old: Patched/fixed-version: only affects 6.19.4 onwards > new: Patched/fixed-version: only affects 6.19 onwards > CVE-2026-23327: > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7) > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc2) > CVE-2026-23328: > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7) > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3) > CVE-2026-23333: > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.4) > new: Unpatched/known-affected: No known resolution > CVE-2026-23341: > old: Patched/fixed-version: only affects 6.19.4 onwards > new: Patched/fixed-version: only affects 6.19 onwards > CVE-2026-23355: > old: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3) > new: Patched/cpe-stable-backport: Backported in 6.18.18 > CVE-2026-23371: > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7) > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3) > CVE-2026-23374: > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7) > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3) > CVE-2026-23377: > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7) > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3) > CVE-2026-23389: > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7) > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3) > CVE-2026-23394: > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.10) > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc5) > > Best regards, > Daniel > > > -----Original Message----- > > From: Benjamin Robin <benjamin.robin@bootlin.com> > > Sent: Friday, 17 April 2026 15:32 > > To: openembedded-core@lists.openembedded.org; Daniel Turull > > <daniel.turull@ericsson.com> > > Subject: Re: [PATCH] improve_kernel_cve_report: use numeric versions > > instead of cpeApplicability > > > > [You don't often get email from benjamin.robin@bootlin.com. Learn why this > > is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > Hello Daniel, > > > > On Friday, April 17, 2026 at 3:24 PM, daniel.turull@ericsson.com wrote: > > > From: Daniel Turull <daniel.turull@ericsson.com> > > > > > > git shas or versions should be use instead of cpeApplicability. > > > Reuse the same logic as generate-cve-exclusions, so outputs are consistent. > > > > > > cpeApplicability does not provide accurate version information and for > > > some CVEs the information is not the same. This came from a > > > discussion that we had with Greg Kroah-Hartma, member of the Linux > > security team. > > > > Indeed "cpeApplicability" does not provide the same kind of information that > > the "versions" node. > > In sbom-cve-check (the latest version in main branch) we are using both > > sources of information. > > But you are saying that "cpeApplicability" does not provide accurate version > > information. Could you elaborate and give various examples? I never saw > > something invalid in "cpeApplicability". > >
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,
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2025/CVE-2025-40067.json
"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"
},
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'll send an email to ask for clarification to the kernel security team and try to see other similar cases. I must say that this is a minority of all CVEs.
Also I need to look if this could be integrated in the sbom-cve-check, so we have it only one place. I want to be able to run the script as well with older releases or just telling the kernel to use without SBOM.
Best regards,
Daniel
> -----Original Message-----
> From: Benjamin Robin <benjamin.robin@bootlin.com>
> Sent: Friday, 17 April 2026 15:55
> To: 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 3:44 PM, Daniel Turull wrote:
> > Hi,
> > We had Greg visiting us and I asked him what is better to use and he said git
> or versions, not cvepAplicability that has issues defining trees.
>
> You reply is technically not responding to my question :) Could you provide at
> least one example with an entry that is not correct in the cpeApplicability
> node?
>
> The script had previously various issue (or at least it looked like it).
> I preferred to use a completely different algorithm (and using all sources of
> information)
>
> But since I am also using NVD entries this degrade a bit the quality of the
> generated assessment message
>
> > I have done some comparison with 6.6.100 and 6.18.22
> >
> >
> > === 6.6.100 ===
> > Old: 10900 New: 10898 Match: 10418 Only old: 2 Only new: 0 Diff: 480
> > 327 Unpatched/version-in-range -> Unpatched/version-in-range
> > 106 Patched/fixed-version -> Patched/fixed-version
> > 16 Patched/cpe-stable-backport -> Unpatched/version-in-range
> > 15 Unpatched/version-in-range -> Patched/fixed-version
> > 5 Patched/fixed-version -> Unpatched/known-affected
> > 5 Patched/fixed-version -> Unpatched/version-in-range
> > 2 Patched/cpe-stable-backport -> Patched/fixed-version
> > 1 Patched/version-not-in-range -> Unpatched/version-in-range
> > 1 Patched/cpe-stable-backport -> Unpatched/known-affected
> > 1 Patched/version-not-in-range -> Patched/fixed-version
> > 1 Unpatched/version-in-range -> Unpatched/known-affected
> > Only in old:
> > CVE-2024-0000: Patched/version-not-in-range
> > CVE-2024-0053: Patched/version-not-in-range
> >
> > === 6.18.22 ===
> > Old: 10900 New: 10898 Match: 10877 Only old: 2 Only new: 0 Diff: 21
> > 7 Unpatched/version-in-range -> Unpatched/version-in-range
> > 6 Patched/fixed-version -> Patched/fixed-version
> > 6 Patched/fixed-version -> Unpatched/known-affected
> > 1 Unpatched/version-in-range -> Unpatched/known-affected
> > 1 Unpatched/version-in-range -> Patched/cpe-stable-backport
> > Only in old:
> > CVE-2024-0000: Patched/version-not-in-range
> > CVE-2024-0053: Patched/version-not-in-range
> >
> > old vs new outputs for kernel 6.18.22
> >
> > Old total: 10900
> > New total: 10898
> > Matching: 10877
> > Only in old: 2
> > Only in new: 0
> > Different: 21
> >
> > Difference categories:
> > 7 Unpatched/version-in-range -> Unpatched/version-in-range
> > 6 Patched/fixed-version -> Patched/fixed-version
> > 6 Patched/fixed-version -> Unpatched/known-affected
> > 1 Unpatched/version-in-range -> Unpatched/known-affected
> > 1 Unpatched/version-in-range -> Patched/cpe-stable-backport
> >
> > Only in old (2):
> > CVE-2024-0000: Patched/version-not-in-range: No CPE match
> > CVE-2024-0053: Patched/version-not-in-range: No CPE match
> >
> > Different (all 21):
> > CVE-2021-47295:
> > old: Patched/fixed-version: Fixed from version 6.2.5
> > new: Patched/fixed-version: Fixed from version 5.14
> > CVE-2021-47342:
> > old: Patched/fixed-version: Fixed from version 5.12.5000
> > new: Patched/fixed-version: Fixed from version 5.10.77
> > CVE-2022-50396:
> > old: Patched/fixed-version: Fixed from version 6.2.5
> > new: Patched/fixed-version: Fixed from version 6.2
> > CVE-2023-53012:
> > old: Patched/fixed-version: Fixed from version 6.1.5000
> > new: Unpatched/known-affected: No known resolution
> > CVE-2023-53187:
> > old: Patched/fixed-version: Fixed from version 5.15.5000
> > new: Unpatched/known-affected: No known resolution
> > CVE-2024-49854:
> > old: Patched/fixed-version: Fixed from version 5.10.5000
> > new: Unpatched/known-affected: No known resolution
> > CVE-2025-38656:
> > old: Patched/fixed-version: Fixed from version 6.12.5000
> > new: Unpatched/known-affected: No known resolution
> > CVE-2025-68195:
> > old: Patched/fixed-version: Fixed from version 6.12.5000
> > new: Unpatched/known-affected: No known resolution
> > CVE-2025-68357:
> > old: Patched/fixed-version: Fixed from version 6.17.5000
> > new: Patched/fixed-version: Fixed from version 6.12.64
> > CVE-2025-71145:
> > old: Patched/fixed-version: Fixed from version 5.10.5000
> > new: Unpatched/known-affected: No known resolution
> > CVE-2026-23288:
> > old: Patched/fixed-version: only affects 6.19.4 onwards
> > new: Patched/fixed-version: only affects 6.19 onwards
> > CVE-2026-23327:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
> > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc2)
> > CVE-2026-23328:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
> > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
> > CVE-2026-23333:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.4)
> > new: Unpatched/known-affected: No known resolution
> > CVE-2026-23341:
> > old: Patched/fixed-version: only affects 6.19.4 onwards
> > new: Patched/fixed-version: only affects 6.19 onwards
> > CVE-2026-23355:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
> > new: Patched/cpe-stable-backport: Backported in 6.18.18
> > CVE-2026-23371:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
> > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
> > CVE-2026-23374:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
> > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
> > CVE-2026-23377:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
> > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
> > CVE-2026-23389:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.7)
> > new: Unpatched/version-in-range: Needs backporting (fixed from 7.0rc3)
> > CVE-2026-23394:
> > old: Unpatched/version-in-range: Needs backporting (fixed from 6.19.10)
> > new: Unpatched/version-in-range: Needs backporting (fixed from
> > 7.0rc5)
> >
> > Best regards,
> > Daniel
> >
> > > -----Original Message-----
> > > From: Benjamin Robin <benjamin.robin@bootlin.com>
> > > Sent: Friday, 17 April 2026 15:32
> > > To: openembedded-core@lists.openembedded.org; Daniel Turull
> > > <daniel.turull@ericsson.com>
> > > Subject: Re: [PATCH] improve_kernel_cve_report: use numeric versions
> > > instead of cpeApplicability
> > >
> > > [You don't often get email from benjamin.robin@bootlin.com. Learn
> > > why this is important at
> > > https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Hello Daniel,
> > >
> > > On Friday, April 17, 2026 at 3:24 PM, daniel.turull@ericsson.com wrote:
> > > > From: Daniel Turull <daniel.turull@ericsson.com>
> > > >
> > > > git shas or versions should be use instead of cpeApplicability.
> > > > Reuse the same logic as generate-cve-exclusions, so outputs are
> consistent.
> > > >
> > > > cpeApplicability does not provide accurate version information and
> > > > for some CVEs the information is not the same. This came from a
> > > > discussion that we had with Greg Kroah-Hartma, member of the Linux
> > > security team.
> > >
> > > Indeed "cpeApplicability" does not provide the same kind of
> > > information that the "versions" node.
> > > In sbom-cve-check (the latest version in main branch) we are using
> > > both sources of information.
> > > But you are saying that "cpeApplicability" does not provide accurate
> > > version information. Could you elaborate and give various examples?
> > > I never saw something invalid in "cpeApplicability".
> > >
>
> --
> Benjamin Robin, Bootlin
> Embedded Linux and Kernel engineering
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbootlin
> .com%2F&data=05%7C02%7Cdaniel.turull%40ericsson.com%7Cdbbb990e606
> 245d2f01c08de9c88ecab%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
> %7C639120309071164067%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=mzgiHIfwb7lLWnnQ%2Fo8KpUkKlUN
> 5KrZb7eij1g%2BTaIg%3D&reserved=0
>
>
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, > https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2025/CVE-2025-40067.json > > "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... > I'll send an email to ask for clarification to the kernel security team and try to see other similar cases. I must say that this is a minority of all CVEs. > > Also I need to look if this could be integrated in the sbom-cve-check, so we have it only one place. I want to be able to run the script as well with older releases or just telling the kernel to use without SBOM. This is already integrated to sbom-cve-check (I pushed today in main), but the algorithm is completely different. And again since NVD database is enabled (by default) the result is not as good as if you are only using the CVEList entries. I was going to propose to drop this Python script that you are working on. > > Best regards, > Daniel > > > > -----Original Message----- > > From: Benjamin Robin <benjamin.robin@bootlin.com> > > Sent: Friday, 17 April 2026 15:55 > > To: 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 3:44 PM, Daniel Turull wrote: > > > Hi, > > > We had Greg visiting us and I asked him what is better to use and he said git > > or versions, not cvepAplicability that has issues defining trees. > > > > You reply is technically not responding to my question :) Could you provide at > > least one example with an entry that is not correct in the cpeApplicability > > node? > > > > The script had previously various issue (or at least it looked like it). > > I preferred to use a completely different algorithm (and using all sources of > > information) > > > > But since I am also using NVD entries this degrade a bit the quality of the > > generated assessment message > > > > > I have done some comparison with 6.6.100 and 6.18.22
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. If we plan to drop the script, I should probably not spend too much time on the script itself but on the data quality. 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, > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fsecurity%2Fvulns.git%2Ftree%2Fcve%2Fpublished%2F2025%2FCVE-2025-40067.json&data=05%7C02%7Cdaniel.turull%40ericsson.com%7C51a3d6a1ffb84372d85e08de9c903527%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639120340343085371%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=o0yl%2FWDeKZqspA3cFaha2hCBt9hvxVkAygWN6UqXlkY%3D&reserved=0<https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2025/CVE-2025-40067.json> > > "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... > I'll send an email to ask for clarification to the kernel security team and try to see other similar cases. I must say that this is a minority of all CVEs. > > Also I need to look if this could be integrated in the sbom-cve-check, so we have it only one place. I want to be able to run the script as well with older releases or just telling the kernel to use without SBOM. This is already integrated to sbom-cve-check (I pushed today in main), but the algorithm is completely different. And again since NVD database is enabled (by default) the result is not as good as if you are only using the CVEList entries. I was going to propose to drop this Python script that you are working on. > > Best regards, > Daniel > > > > -----Original Message----- > > From: Benjamin Robin <benjamin.robin@bootlin.com> > > Sent: Friday, 17 April 2026 15:55 > > To: 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 3:44 PM, Daniel Turull wrote: > > > Hi, > > > We had Greg visiting us and I asked him what is better to use and he said git > > or versions, not cvepAplicability that has issues defining trees. > > > > You reply is technically not responding to my question :) Could you provide at > > least one example with an entry that is not correct in the cpeApplicability > > node? > > > > The script had previously various issue (or at least it looked like it). > > I preferred to use a completely different algorithm (and using all sources of > > information) > > > > But since I am also using NVD entries this degrade a bit the quality of the > > generated assessment message > > > > > I have done some comparison with 6.6.100 and 6.18.22 -- Benjamin Robin, Bootlin Embedded Linux and Kernel engineering https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbootlin.com%2F&data=05%7C02%7Cdaniel.turull%40ericsson.com%7C51a3d6a1ffb84372d85e08de9c903527%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639120340343100584%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xAn%2BE3rQ%2BUyoTyyLFkMBoTgm2ibB328y1PRu0FY9afY%3D&reserved=0<https://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...
> -----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. > > > 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? Thanks Daniel > > 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 > >
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
> -----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. > > > > Thanks > > Daniel > > -- > Benjamin Robin, Bootlin > Embedded Linux and Kernel engineering > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbootlin > .com%2F&data=05%7C02%7Cdaniel.turull%40ericsson.com%7C02c979105b9 > a41cfe17908de9eaea603%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0 > %7C639122670115586461%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG > kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=xJjwN9UNO5bFS5i8MciYNCwue%2FD > yWf5BFd7cwFb%2BrdQ%3D&reserved=0 > >
diff --git a/scripts/contrib/improve_kernel_cve_report.py b/scripts/contrib/improve_kernel_cve_report.py index b386c9383a..a5458f8dd3 100755 --- a/scripts/contrib/improve_kernel_cve_report.py +++ b/scripts/contrib/improve_kernel_cve_report.py @@ -82,16 +82,59 @@ def get_kernel_cves(datadir, compiled_files, version): "description": f"Rejected by CNA" } continue - if any(elem in cve_file for elem in ["review", "reverved", "testing"]): + if any(elem in cve_file for elem in ["review", "reverved", "testing", "tmp"]): continue - is_vulnerable, first_affected, last_affected, better_match_first, better_match_last, affected_versions = get_cpe_applicability(cve_info, version) + first_affected, fixed, backport_ver = get_fixed_versions(cve_info, base_version) - logging.debug("%s: %s (%s - %s) (%s - %s)", cve_id, is_vulnerable, better_match_first, better_match_last, first_affected, last_affected) + logging.debug("%s: first_affected=%s fixed=%s backport=%s", cve_id, first_affected, fixed, backport_ver) - if is_vulnerable is None: - logging.warning("%s doesn't have good metadata", cve_id) - if is_vulnerable: + if not fixed: + logging.warning("%s has no known resolution", cve_id) + cves[cve_id] = { + "id": cve_id, + "status": "Unpatched", + "detail": "known-affected", + "summary": description, + "description": "No known resolution" + } + vulnerable += 1 + continue + elif first_affected and version < first_affected: + logging.debug('%s - fixed-version: only affects %s onwards', + cve_id, first_affected) + cves[cve_id] = { + "id": cve_id, + "status": "Patched", + "detail": "fixed-version", + "summary": description, + "description": f"only affects {first_affected} onwards" + } + not_vulnerable += 1 + elif fixed <= version: + logging.debug("%s - fixed-version: Fixed from version %s", + cve_id, fixed) + cves[cve_id] = { + "id": cve_id, + "status": "Patched", + "detail": "fixed-version", + "summary": description, + "description": f"Fixed from version {fixed}" + } + not_vulnerable += 1 + elif backport_ver and backport_ver <= version: + logging.debug("%s - cpe-stable-backport: Backported in %s", + cve_id, backport_ver) + cves[cve_id] = { + "id": cve_id, + "status": "Patched", + "detail": "cpe-stable-backport", + "summary": description, + "description": f"Backported in {backport_ver}" + } + not_vulnerable += 1 + else: + # Vulnerable - may need backporting is_affected = True affected_files = [] if check_config: @@ -108,87 +151,21 @@ def get_kernel_cves(datadir, compiled_files, version): "summary": description, "description": f"Source code not compiled by config. {sorted(affected_files)}" } - not_applicable_config +=1 - # Check if we have backport + not_applicable_config += 1 else: - if not better_match_last: - fixed_in = last_affected - else: - fixed_in = better_match_last + fixed_in = backport_ver if backport_ver else fixed logging.debug("%s needs backporting (fixed from %s)", cve_id, fixed_in) - cves[cve_id] = { - "id": cve_id, - "status": "Unpatched", - "detail": "version-in-range", - "summary": description, - "description": f"Needs backporting (fixed from {fixed_in})" - } - vulnerable += 1 - if (better_match_last and - Version(f"{better_match_last.major}.{better_match_last.minor}") == base_version): - fixed_as_later_backport += 1 - # Not vulnerable - else: - if not first_affected: - logging.debug("%s - not known affected %s", - cve_id, - better_match_last) cves[cve_id] = { "id": cve_id, - "status": "Patched", - "detail": "version-not-in-range", + "status": "Unpatched", + "detail": "version-in-range", "summary": description, - "description": "No CPE match" + "description": f"Needs backporting (fixed from {fixed_in})" } - not_vulnerable += 1 - continue - backport_base = Version(f"{better_match_last.major}.{better_match_last.minor}") - if version < first_affected: - logging.debug('%s - fixed-version: only affects %s onwards', - cve_id, - first_affected) - cves[cve_id] = { - "id": cve_id, - "status": "Patched", - "detail": "fixed-version", - "summary": description, - "description": f"only affects {first_affected} onwards" - } - not_vulnerable += 1 - elif last_affected <= version: - logging.debug("%s - fixed-version: Fixed from version %s", - cve_id, - last_affected) - cves[cve_id] = { - "id": cve_id, - "status": "Patched", - "detail": "fixed-version", - "summary": description, - "description": f"Fixed from version {last_affected}" - } - not_vulnerable += 1 - elif backport_base == base_version: - logging.debug("%s - cpe-stable-backport: Backported in %s", - cve_id, - better_match_last) - cves[cve_id] = { - "id": cve_id, - "status": "Patched", - "detail": "cpe-stable-backport", - "summary": description, - "description": f"Backported in {better_match_last}" - } - not_vulnerable += 1 - else: - logging.debug("%s - version not affected %s", cve_id, str(affected_versions)) - cves[cve_id] = { - "id": cve_id, - "status": "Patched", - "detail": "version-not-in-range", - "summary": description, - "description": f"Range {affected_versions}" - } - not_vulnerable += 1 + vulnerable += 1 + if (backport_ver and + Version(f"{backport_ver.major}.{backport_ver.minor}") == base_version): + fixed_as_later_backport += 1 logging.info("Total CVEs ignored due to not applicable config: %d", not_applicable_config) logging.info("Total CVEs not vulnerable due version-not-in-range: %d", not_vulnerable) @@ -276,70 +253,54 @@ def check_kernel_compiled_files(compiled_files, cve_info): is_affected = True return is_affected, files_affected -def get_cpe_applicability(cve_info, v): +def get_fixed_versions(cve_info, base_version): ''' - Check if version is affected and return affected versions + Get fixed versionss ''' - base_branch = Version(f"{v.major}.{v.minor}") - affected = [] - if not 'cpeApplicability' in cve_info["containers"]["cna"]: - return None, None, None, None, None, None - - for nodes in cve_info["containers"]["cna"]["cpeApplicability"]: - for node in nodes.values(): - vulnerable = False - matched_branch = False - first_affected = Version("5000") - last_affected = Version("0") - better_match_first = Version("0") - better_match_last = Version("5000") - - if len(node[0]['cpeMatch']) == 0: - first_affected = None - last_affected = None - better_match_first = None - better_match_last = None - - for cpe_match in node[0]['cpeMatch']: - version_start_including = Version("0") - version_end_excluding = Version("0") - if 'versionStartIncluding' in cpe_match: - version_start_including = Version(cpe_match['versionStartIncluding']) - else: - version_start_including = Version("0") - # if versionEndExcluding is missing we are in a branch, which is not fixed. - if "versionEndExcluding" in cpe_match: - version_end_excluding = Version(cpe_match["versionEndExcluding"]) - else: - # if versionEndExcluding is missing we are in a branch, which is not fixed. - version_end_excluding = Version( - f"{version_start_including.major}.{version_start_including.minor}.5000" - ) - affected.append(f" {version_start_including}-{version_end_excluding}") - # Detect if versionEnd is in fixed in base branch. It has precedence over the rest - branch_end = Version(f"{version_end_excluding.major}.{version_end_excluding.minor}") - if branch_end == base_branch: - if version_start_including <= v < version_end_excluding: - vulnerable = cpe_match['vulnerable'] - # If we don't match in our branch, we are not vulnerable, - # since we have a backport - matched_branch = True - better_match_first = version_start_including - better_match_last = version_end_excluding - if version_start_including <= v < version_end_excluding and not matched_branch: - if version_end_excluding < better_match_last: - better_match_first = max(version_start_including, better_match_first) - better_match_last = min(better_match_last, version_end_excluding) - vulnerable = cpe_match['vulnerable'] - matched_branch = True - - first_affected = min(version_start_including, first_affected) - last_affected = max(version_end_excluding, last_affected) - # Not a better match, we use the first and last affected instead of the fake .5000 - if vulnerable and better_match_last == Version(f"{base_branch}.5000"): - better_match_last = last_affected - better_match_first = first_affected - return vulnerable, first_affected, last_affected, better_match_first, better_match_last, affected + first_affected = None + fixed = None + fixed_backport = None + next_version = Version(str(base_version) + ".5000") + for affected in cve_info["containers"]["cna"]["affected"]: + # In case the CVE info is not complete, it might not have default status and therefore + # we don't know the status of this CVE. + if not "defaultStatus" in affected: + return first_affected, fixed, fixed_backport + if affected["defaultStatus"] == "affected": + for version in affected["versions"]: + v = Version(version["version"]) + if v == Version('0'): + #Skiping non-affected + continue + if version["status"] == "unaffected" and first_affected and v < first_affected: + first_affected = Version(f"{v.major}.{v.minor}") + if version["status"] == "affected" and not first_affected: + first_affected = v + elif (version["status"] == "unaffected" and + version['versionType'] == "original_commit_for_fix"): + fixed = v + elif base_version < v and v < next_version: + fixed_backport = v + elif affected["defaultStatus"] == "unaffected": + # Only specific versions are affected. We care only about our base version + if "versions" not in affected: + continue + for version in affected["versions"]: + if "versionType" not in version: + continue + if version["versionType"] == "git": + continue + v = Version(version["version"]) + # in case it is not in our base version + less_than = Version(version["lessThan"]) + + if not first_affected: + first_affected = v + fixed = less_than + if base_version < v and v < next_version: + fixed_backport = less_than + + return first_affected, fixed, fixed_backport def copy_data(old, new): '''Update dictionary with new entries, while keeping the old ones'''