diff mbox series

[RFC] cve-extra-exclusions: add more linux-yocto CVE ignores

Message ID 20230605162546.3012555-1-ross.burton@arm.com
State Accepted, archived
Commit 73f03970f0aadfb053666a1e93f6f6d5b5156ca6
Headers show
Series [RFC] cve-extra-exclusions: add more linux-yocto CVE ignores | expand

Commit Message

Ross Burton June 5, 2023, 4:25 p.m. UTC
From: Ross Burton <ross.burton@arm.com>

These CVEs have all been fixed <6.1.30, which is the default linux-yocto
kernel version.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 .../distro/include/cve-extra-exclusions.inc   | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)

Comments

Ross Burton June 5, 2023, 4:31 p.m. UTC | #1
I did some triage of the CVEs in this list but realised that this file is a bad location for them: whilst we don’t expect people to switch out most recipes, we do have to expect BSPs to switch the kernel, so by accumulating a list of exclusions in this recipe that are based on the current version of linux-yocto we may negatively impact on people using a BSP which, for example, uses a 5.10 kernel.

Should we move the kernel-specific exclusions, where they’re being done because they’re fixed in a release we ship, to the linux-yocto recipe?

Ross
Richard Purdie June 5, 2023, 4:48 p.m. UTC | #2
On Mon, 2023-06-05 at 16:31 +0000, Ross Burton wrote:
> I did some triage of the CVEs in this list but realised that this
> file is a bad location for them: whilst we don’t expect people to
> switch out most recipes, we do have to expect BSPs to switch the
> kernel, so by accumulating a list of exclusions in this recipe that
> are based on the current version of linux-yocto we may negatively
> impact on people using a BSP which, for example, uses a 5.10 kernel.
> 
> Should we move the kernel-specific exclusions, where they’re being
> done because they’re fixed in a release we ship, to the linux-yocto
> recipe?

A specific include with "6.1" in the name might be a good way to do it
so that others who follow the same stable series updates could reuse
it?

Cheers,

Richard
Marta Rybczynska June 6, 2023, 5:35 a.m. UTC | #3
On Mon, Jun 5, 2023 at 6:48 PM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Mon, 2023-06-05 at 16:31 +0000, Ross Burton wrote:
> > I did some triage of the CVEs in this list but realised that this
> > file is a bad location for them: whilst we don’t expect people to
> > switch out most recipes, we do have to expect BSPs to switch the
> > kernel, so by accumulating a list of exclusions in this recipe that
> > are based on the current version of linux-yocto we may negatively
> > impact on people using a BSP which, for example, uses a 5.10 kernel.
> >
> > Should we move the kernel-specific exclusions, where they’re being
> > done because they’re fixed in a release we ship, to the linux-yocto
> > recipe?
>
> A specific include with "6.1" in the name might be a good way to do it
> so that others who follow the same stable series updates could reuse
> it?
>
>
This is definitely better to have a specific file. However, I know some BSPs
that stay at x.0 version of the kernel and if they include such a file,
they will
have a false sense of security...

Kind regards,
Marta
Marta Rybczynska June 6, 2023, 5:37 a.m. UTC | #4
On Mon, Jun 5, 2023 at 6:25 PM Ross Burton <ross.burton@arm.com> wrote:

> From: Ross Burton <ross.burton@arm.com>
>
> These CVEs have all been fixed <6.1.30, which is the default linux-yocto
> kernel version.
>
>
Those are pretty new ones, should be all covered by the new CVE format. Is
anyone already
sending pull requests to include that information in the CVE database
directly (not NVD)?

Kind regards,
Marta
diff mbox series

Patch

diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
index 0ca75bae3ef..ff5d381523c 100644
--- a/meta/conf/distro/include/cve-extra-exclusions.inc
+++ b/meta/conf/distro/include/cve-extra-exclusions.inc
@@ -555,5 +555,46 @@  CVE_CHECK_IGNORE += "CVE-2019-12067"
 # done about the bug, ignore from an OE perspective.
 CVE_CHECK_IGNORE += "CVE-2020-18974"
 
+# https://www.linuxkernelcves.com/cves/CVE-2023-0459
+# Fixed in 6.1.14 onwards
+CVE_CHECK_IGNORE += "CVE-2023-0459"
 
+# https://www.linuxkernelcves.com/cves/CVE-2023-0615
+# Fixed in 6.1 onwards
+CVE_CHECK_IGNORE += "CVE-2023-0615"
 
+# https://www.linuxkernelcves.com/cves/CVE-2023-1380
+# Fixed in 6.1.27
+CVE_CHECK_IGNORE += "CVE-2023-1380"
+
+# https://www.linuxkernelcves.com/cves/CVE-2023-1611
+# Fixed in 6.1.23
+CVE_CHECK_IGNORE += "CVE-2023-1611"
+
+# https://www.linuxkernelcves.com/cves/CVE-2023-1855
+# Fixed in 6.1.21
+CVE_CHECK_IGNORE += "CVE-2023-1855"
+
+# https://www.linuxkernelcves.com/cves/CVE-2023-1859
+# Fixed in 6.1.25
+CVE_CHECK_IGNORE += "CVE-2023-1859"
+
+# https://www.linuxkernelcves.com/cves/CVE-2023-1989
+# Fixed in 6.1.22
+CVE_CHECK_IGNORE += "CVE-2023-1989"
+
+# https://www.linuxkernelcves.com/cves/CVE-2023-1990
+# Fixed in 6.1.21
+CVE_CHECK_IGNORE += "CVE-2023-1990"
+
+# https://www.linuxkernelcves.com/cves/CVE-2023-1999
+# Fixed in 6.1.16
+CVE_CHECK_IGNORE += "CVE-2023-1998"
+
+# https://www.linuxkernelcves.com/cves/CVE-2023-2156
+# Fixed in 6.1.26
+CVE_CHECK_IGNORE += "CVE-2023-2156"
+
+# https://www.linuxkernelcves.com/cves/CVE-2023-2162
+# Fixed in 6.1.11
+CVE_CHECK_IGNORE += "CVE-2023-2162"