[PATCH 1/5] cve_check: handle CVE_STATUS being set to the empty string

[PATCH 1/5] cve_check: handle CVE_STATUS being set to the empty string

[ross.burton]

From: Ross Burton <ross.burton@arm.com>

Handle CVE_STATUS[...] being set to an empty string just as if it was
not set at all.

This is needed for evaluated CVE_STATUS values to work, i.e. when
setting not-applicable-config if a PACKAGECONFIG is disabled.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/lib/oe/cve_check.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/cve_check.py b/meta/lib/oe/cve_check.py
index 3fa77bf9a71..b5fc5364dc8 100644
--- a/meta/lib/oe/cve_check.py
+++ b/meta/lib/oe/cve_check.py
@@ -231,7 +231,7 @@ def decode_cve_status(d, cve):
     Convert CVE_STATUS into status, detail and description.
     """
     status = d.getVarFlag("CVE_STATUS", cve)
-    if status is None:
+    if not status:
         return ("", "", "")
 
     status_split = status.split(':', 1)
@@ -240,7 +240,7 @@ def decode_cve_status(d, cve):
 
     status_mapping = d.getVarFlag("CVE_CHECK_STATUSMAP", detail)
     if status_mapping is None:
-        bb.warn('Invalid detail %s for CVE_STATUS[%s] = "%s", fallback to Unpatched' % (detail, cve, status))
+        bb.warn('Invalid detail "%s" for CVE_STATUS[%s] = "%s", fallback to Unpatched' % (detail, cve, status))
         status_mapping = "Unpatched"
 
     return (status_mapping, detail, description)
-- 
2.34.1

[PATCH 2/5] cve_check: cleanup logging

[ross.burton]

From: Ross Burton <ross.burton@arm.com>

Primarily list the number of patches found, useful when debugging.

Also clean up some bad escaping that caused warnings and use
re.IGNORECASE instead of manually doing case-insenstive rang matches.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/lib/oe/cve_check.py | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/meta/lib/oe/cve_check.py b/meta/lib/oe/cve_check.py
index b5fc5364dc8..ed5c714cb8b 100644
--- a/meta/lib/oe/cve_check.py
+++ b/meta/lib/oe/cve_check.py
@@ -79,20 +79,19 @@ def get_patched_cves(d):
     import re
     import oe.patch
 
-    pn = d.getVar("PN")
-    cve_match = re.compile("CVE:( CVE\-\d{4}\-\d+)+")
+    cve_match = re.compile(r"CVE:( CVE-\d{4}-\d+)+")
 
     # Matches the last "CVE-YYYY-ID" in the file name, also if written
     # in lowercase. Possible to have multiple CVE IDs in a single
     # file name, but only the last one will be detected from the file name.
     # However, patch files contents addressing multiple CVE IDs are supported
     # (cve_match regular expression)
-
-    cve_file_name_match = re.compile(".*([Cc][Vv][Ee]\-\d{4}\-\d+)")
+    cve_file_name_match = re.compile(r".*(CVE-\d{4}-\d+)", re.IGNORECASE)
 
     patched_cves = set()
-    bb.debug(2, "Looking for patches that solves CVEs for %s" % pn)
-    for url in oe.patch.src_patches(d):
+    patches = oe.patch.src_patches(d)
+    bb.debug(2, "Scanning %d patches for CVEs" % len(patches))
+    for url in patches:
         patch_file = bb.fetch.decodeurl(url)[2]
 
         # Check patch file name for CVE ID
@@ -100,7 +99,7 @@ def get_patched_cves(d):
         if fname_match:
             cve = fname_match.group(1).upper()
             patched_cves.add(cve)
-            bb.debug(2, "Found CVE %s from patch file name %s" % (cve, patch_file))
+            bb.debug(2, "Found %s from patch file name %s" % (cve, patch_file))
 
         # Remote patches won't be present and compressed patches won't be
         # unpacked, so say we're not scanning them
-- 
2.34.1

[PATCH 3/5] zlib: ignore CVE-2023-6992

[ross.burton]

From: Ross Burton <ross.burton@arm.com>

This issue is specific to the Cloudflare fork of zlib.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/recipes-core/zlib/zlib_1.3.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/zlib/zlib_1.3.bb b/meta/recipes-core/zlib/zlib_1.3.bb
index 1ed18172faa..9db5588d66a 100644
--- a/meta/recipes-core/zlib/zlib_1.3.bb
+++ b/meta/recipes-core/zlib/zlib_1.3.bb
@@ -47,3 +47,4 @@ do_install_ptest() {
 BBCLASSEXTEND = "native nativesdk"
 
 CVE_STATUS[CVE-2023-45853] = "not-applicable-config: we don't build minizip"
+CVE_STATUS[CVE-2023-6992] = "not-applicable-config: specific to the Cloudflare fork"
-- 
2.34.1

[PATCH 4/5] xserver-xorg: add PACKAGECONFIG for xvfb

[ross.burton]

From: Ross Burton <ross.burton@arm.com>

Xvfb is pretty niche and has outstanding unsolved security issues, so
let people disable it and add a conditional CVE_STATUS to reflect this.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 085fcaf87a5..5a0fceea865 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -116,14 +116,13 @@ FILES:xf86-video-modesetting = "${libdir}/xorg/modules/drivers/modesetting_drv.s
 
 EXTRA_OEMESON += " \
                  -Dxnest=false \
-                 -Dxvfb=true \
                  -Ddtrace=false \
                  -Dint10=x86emu \
                  -Dxkb_output_dir=/var/lib/xkb \
 "
 
 OPENGL_PKGCONFIGS = "dri glx glamor dri3"
-PACKAGECONFIG ??= "dga dri2 udev ${XORG_CRYPTO} \
+PACKAGECONFIG ??= "dga dri2 udev xvfb ${XORG_CRYPTO} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', '${OPENGL_PKGCONFIGS}', '', d)} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd-logind', '', d)} \
 "
@@ -138,6 +137,7 @@ PACKAGECONFIG[glamor] = "-Dglamor=true,-Dglamor=false,libepoxy virtual/libgbm,li
 PACKAGECONFIG[unwind] = "-Dlibunwind=true,-Dlibunwind=false,libunwind"
 PACKAGECONFIG[systemd-logind] = "-Dsystemd_logind=true,-Dsystemd_logind=false,dbus,"
 PACKAGECONFIG[xinerama] = "-Dxinerama=true,-Dxinerama=false"
+PACKAGECONFIG[xvfb] = "-Dxvfb=true,-Dxvfb=false"
 
 # Xorg requires a SHA1 implementation, pick one
 XORG_CRYPTO ??= "openssl"
@@ -175,3 +175,5 @@ python populate_packages:prepend() {
     d.appendVar("RPROVIDES:" + pn, " " + get_abi("input"))
     d.appendVar("RPROVIDES:" + pn, " " + get_abi("video"))
 }
+
+CVE_STATUS[CVE-2023-5574] = "${@bb.utils.contains('PACKAGECONFIG', 'xvfb', '', 'not-applicable-config: specific to Xvfb', d)}"
-- 
2.34.1

[PATCH 5/5] xserver-xorg: disable xvfb by default

[ross.burton]

From: Ross Burton <ross.burton@arm.com>

xvfb has limited use, so to mitigate CVE-2023-5574 out of the box we can
disable the xvfb PACKAGECONFIG.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 5a0fceea865..22f7d9a8adc 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -122,7 +122,7 @@ EXTRA_OEMESON += " \
 "
 
 OPENGL_PKGCONFIGS = "dri glx glamor dri3"
-PACKAGECONFIG ??= "dga dri2 udev xvfb ${XORG_CRYPTO} \
+PACKAGECONFIG ??= "dga dri2 udev ${XORG_CRYPTO} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', '${OPENGL_PKGCONFIGS}', '', d)} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd-logind', '', d)} \
 "
-- 
2.34.1

RE: [OE-core] [PATCH 3/5] zlib: ignore CVE-2023-6992

[Marko, Peter]

Hi Ross,

I think this one is better - https://lists.openembedded.org/g/openembedded-core/message/193603
I'm not sure why it was not picked up yet after 9 days, but It's CPE which is not matching, not our configuration options...

Peter

-----Original Message-----
From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Ross Burton via lists.openembedded.org
Sent: Monday, January 22, 2024 15:04
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 3/5] zlib: ignore CVE-2023-6992

> From: Ross Burton <ross.burton@arm.com>
>
> This issue is specific to the Cloudflare fork of zlib.
>
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>  meta/recipes-core/zlib/zlib_1.3.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/zlib/zlib_1.3.bb b/meta/recipes-core/zlib/zlib_1.3.bb
> index 1ed18172faa..9db5588d66a 100644
> --- a/meta/recipes-core/zlib/zlib_1.3.bb
> +++ b/meta/recipes-core/zlib/zlib_1.3.bb
> @@ -47,3 +47,4 @@ do_install_ptest() {
>  BBCLASSEXTEND = "native nativesdk"
>  
>  CVE_STATUS[CVE-2023-45853] = "not-applicable-config: we don't build minizip"
> +CVE_STATUS[CVE-2023-6992] = "not-applicable-config: specific to the Cloudflare fork"
> -- 
> 2.34.1

Re: [OE-core] [PATCH 3/5] zlib: ignore CVE-2023-6992

[Ross Burton]

On 22 Jan 2024, at 14:16, Marko, Peter <Peter.Marko@siemens.com> wrote:
> 
> Hi Ross,
> 
> I think this one is better - https://lists.openembedded.org/g/openembedded-core/message/193603
> I'm not sure why it was not picked up yet after 9 days, but It's CPE which is not matching, not our configuration options…

Ah I didn’t see that.

However the CPE _is_ correct, its our matching which is not.  I assumed there wasn’t enough consistency in the zlib CPEs that we could set one with a vendor.

Ross

RE: [OE-core] [PATCH 3/5] zlib: ignore CVE-2023-6992

[Marko, Peter]

-----Original Message-----
From: Ross Burton <Ross.Burton@arm.com> 
Sent: Monday, January 22, 2024 15:27
To: Marko, Peter (ADV D EU SK BFS1) <Peter.Marko@siemens.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 3/5] zlib: ignore CVE-2023-6992

> On 22 Jan 2024, at 14:16, Marko, Peter <Peter.Marko@siemens.com> wrote:
> > 
> > Hi Ross,
> > 
> > I think this one is better - https://lists.openembedded.org/g/openembedded-core/message/193603
> > I'm not sure why it was not picked up yet after 9 days, but It's CPE which is not matching, not our configuration options…
>
> Ah I didn’t see that.
>
> However the CPE _is_ correct, its our matching which is not.  I assumed there wasn’t enough consistency in the zlib CPEs that we could set one with a vendor.

Yes, it’s inconsistency on our side but still in CPE field. Current CVE status option do not offer better selection.
My commit message explains why I have chosen the way to ignore it although it will be in the recipe forever (as version 2023-11-16 will be always higher than PV)
But I can also resubmit with changing CVE_PRODUCT to "gnu:zlib zlib:zlib" if that is the preferred option to go forward.

Peter

>
> Ross