[OE-core] [PATCH 1/1] iputils: update to 20221126
From: Petr Vorel
This release removed: ninfod, rarpd, rdisc.
Remove also related, not yet upstreamed patch.
Signed-off-by: Petr Vorel
---
Hi all,
I'm sorry, I haven't managed to test patch.
Can anybody do it for me?
Thank you.
Kind regards,
Petr
.../0001-rarpd-rdisc-Drop-PrivateUsers.patch | 27 ---
...putils_20211215.bb => iputils_20221126.bb} | 21 +++
2 files changed, 4 insertions(+), 44 deletions(-)
delete mode 100644
meta/recipes-extended/iputils/iputils/0001-rarpd-rdisc-Drop-PrivateUsers.patch
rename meta/recipes-extended/iputils/{iputils_20211215.bb =>
iputils_20221126.bb} (66%)
diff --git
a/meta/recipes-extended/iputils/iputils/0001-rarpd-rdisc-Drop-PrivateUsers.patch
b/meta/recipes-extended/iputils/iputils/0001-rarpd-rdisc-Drop-PrivateUsers.patch
deleted file mode 100644
index c61e39dc80..00
---
a/meta/recipes-extended/iputils/iputils/0001-rarpd-rdisc-Drop-PrivateUsers.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From dfeeb3f1328d09f516edeb6349bd63e3c87f9397 Mon Sep 17 00:00:00 2001
-From: Alex Kiernan
-Date: Thu, 13 Feb 2020 06:08:45 +
-Subject: [PATCH] rarpd:Drop PrivateUsers
-
-rarpd cannot gain the necessary capabilities with
-PrivateUsers enabled.
-
-Upstream-Status: Pending
-Signed-off-by: Alex Kiernan
-
- systemd/rarpd.service.in | 1 -
- 1 file changed, 1 deletion(-)
-
-diff --git a/systemd/rarpd.service.in b/systemd/rarpd.service.in
-index e600c10..f5d7621 100644
a/systemd/rarpd.service.in
-+++ b/systemd/rarpd.service.in
-@@ -12,7 +12,6 @@ AmbientCapabilities=CAP_NET_RAW
- DynamicUser=yes
- PrivateTmp=yes
- PrivateDevices=yes
--PrivateUsers=yes
- ProtectSystem=strict
- ProtectHome=yes
- ProtectControlGroups=yes
diff --git a/meta/recipes-extended/iputils/iputils_20211215.bb
b/meta/recipes-extended/iputils/iputils_20221126.bb
similarity index 66%
rename from meta/recipes-extended/iputils/iputils_20211215.bb
rename to meta/recipes-extended/iputils/iputils_20221126.bb
index 3ddce0be54..b4ab2fce5e 100644
--- a/meta/recipes-extended/iputils/iputils_20211215.bb
+++ b/meta/recipes-extended/iputils/iputils_20221126.bb
@@ -11,9 +11,8 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=bb64c89bb0e23b72930d2380894c47a1"
DEPENDS = "gnutls"
SRC_URI = "git://github.com/iputils/iputils;branch=master;protocol=https \
- file://0001-rarpd-rdisc-Drop-PrivateUsers.patch \
"
-SRCREV = "1d1e7c43210d8af316a41cb2c53d612a4c16f34d"
+SRCREV = "5ffabc4190cab975c7332645259e286a032e183b"
S = "${WORKDIR}/git"
@@ -23,14 +22,12 @@ UPSTREAM_CHECK_GITTAGREGEX = "(?P20\d+)"
# breaks the version order.
CVE_CHECK_IGNORE += "CVE-2000-1213 CVE-2000-1214"
-PACKAGECONFIG ??= "libcap rarpd \
- ${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', 'ninfod',
'', d)} \
+PACKAGECONFIG ??= "libcap \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', '', d)} \
${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
PACKAGECONFIG[libcap] = "-DUSE_CAP=true, -DUSE_CAP=false
-DNO_SETCAP_OR_SUID=true, libcap libcap-native"
PACKAGECONFIG[libidn] = "-DUSE_IDN=true, -DUSE_IDN=false, libidn2"
PACKAGECONFIG[gettext] = "-DUSE_GETTEXT=true, -DUSE_GETTEXT=false, gettext"
-PACKAGECONFIG[ninfod] = "-DBUILD_NINFOD=true,-DBUILD_NINFOD=false,"
-PACKAGECONFIG[rarpd] = "-DBUILD_RARPD=true,-DBUILD_RARPD=false,"
PACKAGECONFIG[systemd] = "-Dsystemdunitdir=${systemd_system_unitdir},,systemd"
PACKAGECONFIG[docs] = "-DBUILD_HTML_MANS=true
-DBUILD_MANS=true,-DBUILD_HTML_MANS=false -DBUILD_MANS=false, libxslt"
@@ -43,9 +40,7 @@ ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE:${PN}-ping = "ping"
ALTERNATIVE_LINK_NAME[ping] = "${base_bindir}/ping"
-SPLITPKGS = "${PN}-ping ${PN}-arping ${PN}-tracepath ${PN}-clockdiff
${PN}-rdisc \
- ${@bb.utils.contains('PACKAGECONFIG', 'rarpd', '${PN}-rarpd', '',
d)} \
- ${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', '${PN}-ninfod',
'', d)}"
+SPLITPKGS = "${PN}-ping ${PN}-arping ${PN}-tracepath ${PN}-clockdiff \
PACKAGES += "${SPLITPKGS}"
ALLOW_EMPTY:${PN} = "1"
@@ -56,11 +51,3 @@ FILES:${PN}-ping = "${base_bindir}/ping.${BPN}"
FILES:${PN}-arping = "${base_bindir}/arping"
FILES:${PN}-tracepath = "${base_bindir}/tracepath"
FILES:${PN}-clockdiff = "${base_bindir}/clockdiff"
-FILES:${PN}-rarpd = "${base_sbindir}/rarpd
${systemd_system_unitdir}/rarpd@.service"
-FILES:${PN}-rdisc = "${base_sbindir}/rdisc"
-FILES:${PN}-ninfod = "${base_sbindir}/ninfod ${sysconfdir}/init.d/ninfod.sh"
-
-SYSTEMD_PACKAGES = "${@bb.utils.contains('DISTRO_FEATURES', 'ipv6',
'${PN}-ninfod', '', d)} \
-${PN}-rdisc"
-SYSTEMD_SERVICE:${PN}-ninfod = "ninfod.service"
-SYSTEMD_SERVICE:${PN}-rdisc = "rdisc.service"
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173790):
https://lists.openembedded.org/g/openembedded-core/message/173790
Mute This Topic: https://lists.openembedded.org/mt/95265570/21656
Group Owne
[OE-core] [PATCH v4] mesa: enable glvnd support
Allows mesa to be built with glvnd support.
Thus, creates libEGL_mesa.so* and libGLX_mesa.so*
mesa(vendor) libraries meant to coexist with vendor
neutral dispatch libraries from libglvnd.
Signed-off-by: Vincent Davis Jr
---
.../conf/distro/include/default-providers.inc | 1 +
meta/recipes-graphics/mesa/mesa.inc | 20 +--
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index 6defdca12d..3a4e989c1f 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -5,6 +5,7 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xorg"
PREFERRED_PROVIDER_virtual/egl ?= "mesa"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
+PREFERRED_PROVIDER_virtual/libglx ?= "mesa"
PREFERRED_PROVIDER_virtual/libgl-native ?= "mesa-native"
PREFERRED_PROVIDER_virtual/nativesdk-libgl ?= "nativesdk-mesa"
PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 1949fc15a9..115621228a 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -32,15 +32,18 @@ UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
#because we cannot rely on the fact that all apps will use pkgconfig,
#make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
do_install:append() {
-if ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)}; then
-sed -i -e 's/^#elif defined(__unix__) && defined(EGL_NO_X11)$/#elif
defined(__unix__) \&\& defined(EGL_NO_X11) ||
${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/'
${D}${includedir}/EGL/eglplatform.h
-fi
+ # sed can't find EGL/eglplatform.h as it doesn't get installed when glvnd
enabled.
+ # So, check if EGL/eglplatform.h exists before running sed.
+ if ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)} && [ -f
${D}${includedir}/EGL/eglplatform.h ]; then
+ sed -i -e 's/^#elif defined(__unix__) && defined(EGL_NO_X11)$/#elif
defined(__unix__) \&\& defined(EGL_NO_X11) ||
${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/'
${D}${includedir}/EGL/eglplatform.h
+ fi
}
DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native
zlib chrpath-replacement-native python3-mako-native gettext-native"
EXTRANATIVEPATH += "chrpath-native"
PROVIDES = " \
${@bb.utils.contains('PACKAGECONFIG', 'opengl', 'virtual/libgl', '', d)} \
+${@bb.utils.contains('PACKAGECONFIG', 'glvnd', 'virtual/libglx', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'gles', 'virtual/libgles1
virtual/libgles2 virtual/libgles3', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'egl', 'virtual/egl', '', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'virtual/libgbm', '', d)} \
@@ -109,6 +112,7 @@ VULKAN_DRIVERS:append
="${@bb.utils.contains('PACKAGECONFIG', 'broadcom', ',broa
PACKAGECONFIG[vulkan] =
"-Dvulkan-drivers=${@strip_comma('${VULKAN_DRIVERS}')},
-Dvulkan-drivers='',glslang-native vulkan-loader vulkan-headers"
PACKAGECONFIG[opengl] = "-Dopengl=true, -Dopengl=false"
+PACKAGECONFIG[glvnd] = "-Dglvnd=true, -Dglvnd=false, libglvnd"
# "gles" requires "opengl"
PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled, -Dgles1=disabled
-Dgles2=disabled"
@@ -199,6 +203,7 @@ RDEPENDS:libopencl-mesa +=
"${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'lib
PACKAGES =+ "libegl-mesa libegl-mesa-dev \
libosmesa libosmesa-dev \
libgl-mesa libgl-mesa-dev \
+ libglx-mesa libglx-mesa-dev \
libglapi libglapi-dev \
libgbm libgbm-dev \
libgles1-mesa libgles1-mesa-dev \
@@ -217,7 +222,7 @@ do_install:append () {
rm -f ${D}${libdir}/gallium-pipe/*.la
rm -f ${D}${libdir}/gbm/*.la
-# it was packaged in libdricore9.1.3-1 and preventing upgrades when
debian.bbclass was used
+# it was packaged in libdricore9.1.3-1 and preventing upgrades when
debian.bbclass was used
chrpath --delete ${D}${libdir}/dri/*_dri.so || true
# libwayland-egl has been moved to wayland 1.15+
@@ -235,6 +240,7 @@ python __anonymous() {
suffix = "-native"
for p in (("egl", "libegl", "libegl1"),
("opengl", "libgl", "libgl1"),
+ ("glvnd", "libglx",),
("gles", "libgles1", "libglesv1-cm1"),
("gles", "libgles2", "libglesv2-2"),
("gles", "libgles3",),
@@ -293,20 +299,22 @@ PACKAGES_DYNAMIC:class-native = "^mesa-driver-.*-native"
FILES:mesa-megadriver = "${libdir}/dri/* ${datadir}/drirc.d"
FILES:mesa-vulkan-drivers = "${libdir}/libvulkan_*.so ${datadir}/vulkan"
FILES:${PN}-vdpau-drivers = "${libdir}/vdpau/*.so.*"
-FILES:libegl-mesa = "${libdir}/libEGL.so.*"
+FILES:libegl-mesa = "${libdir}/libEGL*.so.* ${datadir}/glvn
[OE-core] [PATCH v2] gawk: update 5.1.1 -> 5.2.1
Place gawkbug into a separate package, as it includes target information
which causes multilib conflicts.
Adjust ptests so they are correctly executed:
- unset LANG before starting
- do not patch /usr/local/bin into /usr/bin; this is not correct
Signed-off-by: Alexander Kanavin
---
.../gawk/gawk/remove-sensitive-tests.patch| 35 ++-
meta/recipes-extended/gawk/gawk/run-ptest | 2 +-
.../gawk/{gawk_5.1.1.bb => gawk_5.2.1.bb} | 9 +++--
3 files changed, 35 insertions(+), 11 deletions(-)
rename meta/recipes-extended/gawk/{gawk_5.1.1.bb => gawk_5.2.1.bb} (86%)
diff --git a/meta/recipes-extended/gawk/gawk/remove-sensitive-tests.patch
b/meta/recipes-extended/gawk/gawk/remove-sensitive-tests.patch
index 167c0787ee..ffae55058b 100644
--- a/meta/recipes-extended/gawk/gawk/remove-sensitive-tests.patch
+++ b/meta/recipes-extended/gawk/gawk/remove-sensitive-tests.patch
@@ -1,24 +1,43 @@
+From 354d24baf7c51977d22ff61ad42e6a2cbd4dc8ac Mon Sep 17 00:00:00 2001
+From: Ross Burton
+Date: Tue, 21 Dec 2021 17:09:12 +
+Subject: [PATCH] gawk: remove load-sensitive tests
+
These tests require an unloaded host as otherwise timing sensitive tests can
fail
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14371
Upstream-Status: Inappropriate
Signed-off-by: Ross Burton
a/test/Maketests~
-+++ b/test/Maketests
-@@ -2069,7 +2069,2 @@
+---
+ test/Maketests | 10 --
+ 1 file changed, 10 deletions(-)
+diff --git a/test/Maketests b/test/Maketests
+index 3a667af..f117697 100644
+--- a/test/Maketests
b/test/Maketests
+@@ -2137,11 +2137,6 @@ symtab12:
+ @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
+ @-$(CMP) "$(srcdir)"/$@.ok _$@ && rm -f _$@
+
-timeout:
- @echo $@ $(ZOS_FAIL)
-- @AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE: $$?
>>_$@
+- @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
- @-$(CMP) "$(srcdir)"/$@.ok _$@ && rm -f _$@
-
typedregex1:
-@@ -2297,7 +2292,2 @@
+ @echo $@
+ @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
+@@ -2371,11 +2366,6 @@ rwarray:
+ @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk < "$(srcdir)"/$@.in >_$@ 2>&1
|| echo EXIT CODE: $$? >>_$@
@-$(CMP) "$(srcdir)"/$@.ok _$@ && rm -f _$@
--
+
-time:
- @echo $@
-- @AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE: $$?
>>_$@
+- @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
- @-$(CMP) "$(srcdir)"/$@.ok _$@ && rm -f _$@
-
+-
+ mpfrbigint:
+ @echo $@
+ @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk -M >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
diff --git a/meta/recipes-extended/gawk/gawk/run-ptest
b/meta/recipes-extended/gawk/gawk/run-ptest
index f67a95874f..2675650600 100644
--- a/meta/recipes-extended/gawk/gawk/run-ptest
+++ b/meta/recipes-extended/gawk/gawk/run-ptest
@@ -2,7 +2,7 @@
cd test
for i in `grep -E "^[a-z0-9_-]*:$" Maketests |awk -F: '{print $1}'`; do
- #LC_ALL=${GAWKLOCALE:-C} LANG=${GAWKLOCALE:-C}
+ unset LANG
srcdir=`pwd` AWKPROG=gawk AWK=gawk CMP=cmp make -f Maketests $i >$i.tmp 2>&1
if [ -e _$i ]; then
cat _$i
diff --git a/meta/recipes-extended/gawk/gawk_5.1.1.bb
b/meta/recipes-extended/gawk/gawk_5.2.1.bb
similarity index 86%
rename from meta/recipes-extended/gawk/gawk_5.1.1.bb
rename to meta/recipes-extended/gawk/gawk_5.2.1.bb
index fe339805d0..fbe6e7040b 100644
--- a/meta/recipes-extended/gawk/gawk_5.1.1.bb
+++ b/meta/recipes-extended/gawk/gawk_5.2.1.bb
@@ -20,13 +20,16 @@ SRC_URI = "${GNU_MIRROR}/gawk/gawk-${PV}.tar.gz \
file://run-ptest \
"
-SRC_URI[sha256sum] =
"6168d8d1dc8f74bd17d9dc22fa9634c49070f232343b744901da15fb4f06bffd"
+SRC_URI[sha256sum] =
"529e7c8c6acf21ff3a6183f4d763c632810908989c24675c77995d51ac37b79c"
inherit autotools gettext texinfo update-alternatives
FILES:${PN} += "${datadir}/awk"
FILES:${PN}-dev += "${libdir}/${BPN}/*.la"
+PACKAGES =+ "${PN}-gawkbug"
+FILES:${PN}-gawkbug += "${bindir}/gawkbug"
+
ALTERNATIVE:${PN} = "awk"
ALTERNATIVE_TARGET[awk] = "${bindir}/gawk"
ALTERNATIVE_PRIORITY = "100"
@@ -34,6 +37,8 @@ ALTERNATIVE_PRIORITY = "100"
do_install:append() {
# remove the link since we don't package it
rm ${D}${bindir}/awk
+ # Strip non-reproducible build flags (containing build paths)
+ sed -i -e 's|^CC.*|CC=""|g' -e 's|^CFLAGS.*|CFLAGS=""|g'
${D}${bindir}/gawkbug
}
inherit ptest
@@ -46,7 +51,7 @@ do_install_ptest() {
for i in $TESTS Maketests inclib.awk; do
cp ${S}/test/$i* ${D}${PTEST_PATH}/test
done
- sed -i -e 's|/usr/local/bin|${bindir}|g' \
+ sed -i \
-e 's|#!${base_bindir}/awk|#!${bindir}/awk|g'
${D}${PTEST_PATH}/test/*.awk
sed -i -e "s|GAWKLOCALE|LANG|g" ${D}${PTEST_PATH}/test/Maketests
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all
[OE-core] [PATCH 1/3] qemu-helper: depend on unfs3 and pseudo directly
Dependencies of runqemu belong in qemu-helper; in particular
there is no reason to scatter unfs3 all over the place, and then
require separate steps to make it available (e.g. 'meta-ide-support').
With this, startng runqemu with a nfs mount starts to 'just work'
after building an image.
Signed-off-by: Alexander Kanavin
---
meta/recipes-core/meta/meta-extsdk-toolchain.bb | 2 +-
meta/recipes-core/meta/meta-ide-support.bb| 2 +-
.../packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 -
meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb | 2 +-
meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb | 2 +-
scripts/runqemu-export-rootfs | 8 ++--
scripts/runqemu-extract-sdk | 2 +-
7 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-core/meta/meta-extsdk-toolchain.bb
b/meta/recipes-core/meta/meta-extsdk-toolchain.bb
index 0df681ac73..618b596e4d 100644
--- a/meta/recipes-core/meta/meta-extsdk-toolchain.bb
+++ b/meta/recipes-core/meta/meta-extsdk-toolchain.bb
@@ -2,7 +2,7 @@ SUMMARY = "Extensible SDK toolchain meta-recipe"
DESCRIPTION = "Meta-recipe for ensuring the build directory contains all
appropriate toolchain packages for using an IDE"
LICENSE = "MIT"
-DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native
qemu-helper-native unfs3-native"
+DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native
qemu-helper-native"
do_populate_sysroot[deptask] = "do_populate_sysroot"
diff --git a/meta/recipes-core/meta/meta-ide-support.bb
b/meta/recipes-core/meta/meta-ide-support.bb
index 7f349f673d..dd11b5673c 100644
--- a/meta/recipes-core/meta/meta-ide-support.bb
+++ b/meta/recipes-core/meta/meta-ide-support.bb
@@ -2,7 +2,7 @@ SUMMARY = "Integrated Development Environment support"
DESCRIPTION = "Meta package for ensuring the build directory contains all
appropriate toolchain packages for using an IDE"
LICENSE = "MIT"
-DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native
qemu-helper-native unfs3-native cmake-native autoconf-native automake-native
meson-native intltool-native pkgconfig-native"
+DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native
qemu-helper-native cmake-native autoconf-native automake-native meson-native
intltool-native pkgconfig-native"
PR = "r3"
RM_WORK_EXCLUDE += "${PN}"
diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index 9166a0851f..84ee1e3fa1 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -16,7 +16,6 @@ RDEPENDS:${PN} = "\
nativesdk-qemu \
nativesdk-qemu-helper \
nativesdk-pseudo \
-nativesdk-unfs3 \
nativesdk-opkg \
nativesdk-libtool \
nativesdk-autoconf \
diff --git a/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb
b/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb
index abba7fe159..2a5bcfb909 100644
--- a/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb
+++ b/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb
@@ -1,6 +1,6 @@
SUMMARY = "Qemu helper scripts"
LICENSE = "GPL-2.0-only"
-RDEPENDS:${PN} = "nativesdk-qemu \
+RDEPENDS:${PN} = "nativesdk-qemu nativesdk-unfs3 nativesdk-pseudo \
nativesdk-python3-shell nativesdk-python3-fcntl
nativesdk-python3-logging \
"
diff --git a/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb
b/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb
index e297586bbb..6053b71717 100644
--- a/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb
+++ b/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb
@@ -25,5 +25,5 @@ do_install() {
install qemu-oe-bridge-helper ${D}${bindir}/
}
-DEPENDS += "qemu-system-native"
+DEPENDS += "qemu-system-native unfs3-native pseudo-native"
addtask addto_recipe_sysroot after do_populate_sysroot before do_build
diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs
index c1fff7fcb3..6a8acd0d5a 100755
--- a/scripts/runqemu-export-rootfs
+++ b/scripts/runqemu-export-rootfs
@@ -34,16 +34,12 @@ if [ -z "$SYSROOT_SETUP_SCRIPT" ]; then
echo "Did you forget to source your build environment setup script?"
exit 1
fi
-. $SYSROOT_SETUP_SCRIPT meta-ide-support
+. $SYSROOT_SETUP_SCRIPT qemu-helper-native
if [ ! -e "$OECORE_NATIVE_SYSROOT/usr/bin/unfsd" ]; then
echo "Error: Unable to find unfsd binary in
$OECORE_NATIVE_SYSROOT/usr/bin/"
- if [ "x$OECORE_DISTRO_VERSION" = "x" ]; then
- echo "Have you run 'bitbake meta-ide-support'?"
- else
- echo "This shouldn't happen - something is missing from your
toolchain installation"
- fi
+ echo "This shouldn't happen - something is missing from your toolchain
installation"
exit 1
fi
diff --
[OE-core] [PATCH 2/3] runqemu: do not hardcode the ip address of the nfs server when using tap
Rather, set it similarly to the overall network config.
Signed-off-by: Alexander Kanavin
---
scripts/runqemu | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 7bd9465593..04728673de 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -999,7 +999,7 @@ class BaseConfig(object):
if self.slirp_enabled:
self.nfs_server = '10.0.2.2'
else:
-self.nfs_server = '192.168.7.1'
+self.nfs_server = '192.168.7.@GATEWAY@'
# Figure out a new nfs_instance to allow multiple qemus running.
ps = subprocess.check_output(("ps", "auxww")).decode('utf-8')
@@ -1187,6 +1187,7 @@ class BaseConfig(object):
netconf = " " + self.cmdline_ip_tap
netconf = netconf.replace('@CLIENT@', str(client))
netconf = netconf.replace('@GATEWAY@', str(gateway))
+self.nfs_server = self.nfs_server.replace('@GATEWAY@', str(gateway))
logger.info("Network configuration:%s", netconf)
self.kernel_cmdline_script += netconf
mac = "%s%02x" % (self.mac_tap, client)
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173786):
https://lists.openembedded.org/g/openembedded-core/message/173786
Mute This Topic: https://lists.openembedded.org/mt/95262051/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] selftest/runqemu: reenable the nfs rootfs test
With the previous fixes the test can be run again,
and it doesn't need all those extra steps. Runqemu
takes care of everything automatically now.
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/selftest/cases/runqemu.py | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/runqemu.py
b/meta/lib/oeqa/selftest/cases/runqemu.py
index 58a4526df6..c2c3fbc924 100644
--- a/meta/lib/oeqa/selftest/cases/runqemu.py
+++ b/meta/lib/oeqa/selftest/cases/runqemu.py
@@ -199,22 +199,12 @@ class QemuTest(OESelftestTestCase):
qemu_shutdown_succeeded =
self._start_qemu_shutdown_check_if_shutdown_succeeded(qemu, shutdown_timeout)
self.assertTrue(qemu_shutdown_succeeded, 'Failed: %s does not
shutdown within timeout(%s)' % (self.machine, shutdown_timeout))
-# Need to have portmap/rpcbind running to allow this test to work and
-# current autobuilder setup does not have this.
-def disabled_test_qemu_can_boot_nfs_and_shutdown(self):
-self.assertExists(self.qemuboot_conf)
-bitbake('meta-ide-support')
+def test_qemu_can_boot_nfs_and_shutdown(self):
rootfs_tar = "%s-%s.tar.bz2" % (self.recipe, self.machine)
rootfs_tar = os.path.join(self.deploy_dir_image, rootfs_tar)
self.assertExists(rootfs_tar)
-tmpdir = tempfile.mkdtemp(prefix='qemu_nfs')
-tmpdir_nfs = os.path.join(tmpdir, 'nfs')
-cmd_extract_nfs = 'runqemu-extract-sdk %s %s' % (rootfs_tar,
tmpdir_nfs)
-result = runCmd(cmd_extract_nfs)
-self.assertEqual(0, result.status, "runqemu-extract-sdk didn't run as
expected. %s" % result.output)
-cmd = "%s nfs %s %s" % (self.cmd_common, self.qemuboot_conf,
tmpdir_nfs)
+cmd = "%s %s" % (self.cmd_common, rootfs_tar)
shutdown_timeout = 120
with runqemu(self.recipe, ssh=False, launch_cmd=cmd) as qemu:
qemu_shutdown_succeeded =
self._start_qemu_shutdown_check_if_shutdown_succeeded(qemu, shutdown_timeout)
self.assertTrue(qemu_shutdown_succeeded, 'Failed: %s does not
shutdown within timeout(%s)' % (self.machine, shutdown_timeout))
-runCmd('rm -rf %s' % tmpdir)
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173787):
https://lists.openembedded.org/g/openembedded-core/message/173787
Mute This Topic: https://lists.openembedded.org/mt/95262052/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] gawk: update 5.1.1 -> 5.2.1
Place gawkbug into a separate package, as it includes target information
which causes multilib conflicts.
Adjust ptests so they are correctly executed:
- unset LANG before starting
- do not patch /usr/local/bin into /usr/bin; this is not correct
Runtime fails:
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/6143/steps/13/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/6081/steps/12/logs/stdio
Signed-off-by: Alexander Kanavin
---
.../gawk/gawk/remove-sensitive-tests.patch| 35 ++-
meta/recipes-extended/gawk/gawk/run-ptest | 2 +-
.../gawk/{gawk_5.1.1.bb => gawk_5.2.1.bb} | 9 +++--
3 files changed, 35 insertions(+), 11 deletions(-)
rename meta/recipes-extended/gawk/{gawk_5.1.1.bb => gawk_5.2.1.bb} (86%)
diff --git a/meta/recipes-extended/gawk/gawk/remove-sensitive-tests.patch
b/meta/recipes-extended/gawk/gawk/remove-sensitive-tests.patch
index 167c0787ee..ffae55058b 100644
--- a/meta/recipes-extended/gawk/gawk/remove-sensitive-tests.patch
+++ b/meta/recipes-extended/gawk/gawk/remove-sensitive-tests.patch
@@ -1,24 +1,43 @@
+From 354d24baf7c51977d22ff61ad42e6a2cbd4dc8ac Mon Sep 17 00:00:00 2001
+From: Ross Burton
+Date: Tue, 21 Dec 2021 17:09:12 +
+Subject: [PATCH] gawk: remove load-sensitive tests
+
These tests require an unloaded host as otherwise timing sensitive tests can
fail
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14371
Upstream-Status: Inappropriate
Signed-off-by: Ross Burton
a/test/Maketests~
-+++ b/test/Maketests
-@@ -2069,7 +2069,2 @@
+---
+ test/Maketests | 10 --
+ 1 file changed, 10 deletions(-)
+diff --git a/test/Maketests b/test/Maketests
+index 3a667af..f117697 100644
+--- a/test/Maketests
b/test/Maketests
+@@ -2137,11 +2137,6 @@ symtab12:
+ @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
+ @-$(CMP) "$(srcdir)"/$@.ok _$@ && rm -f _$@
+
-timeout:
- @echo $@ $(ZOS_FAIL)
-- @AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE: $$?
>>_$@
+- @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
- @-$(CMP) "$(srcdir)"/$@.ok _$@ && rm -f _$@
-
typedregex1:
-@@ -2297,7 +2292,2 @@
+ @echo $@
+ @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
+@@ -2371,11 +2366,6 @@ rwarray:
+ @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk < "$(srcdir)"/$@.in >_$@ 2>&1
|| echo EXIT CODE: $$? >>_$@
@-$(CMP) "$(srcdir)"/$@.ok _$@ && rm -f _$@
--
+
-time:
- @echo $@
-- @AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE: $$?
>>_$@
+- @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
- @-$(CMP) "$(srcdir)"/$@.ok _$@ && rm -f _$@
-
+-
+ mpfrbigint:
+ @echo $@
+ @-AWKPATH="$(srcdir)" $(AWK) -f $@.awk -M >_$@ 2>&1 || echo EXIT CODE:
$$? >>_$@
diff --git a/meta/recipes-extended/gawk/gawk/run-ptest
b/meta/recipes-extended/gawk/gawk/run-ptest
index f67a95874f..2675650600 100644
--- a/meta/recipes-extended/gawk/gawk/run-ptest
+++ b/meta/recipes-extended/gawk/gawk/run-ptest
@@ -2,7 +2,7 @@
cd test
for i in `grep -E "^[a-z0-9_-]*:$" Maketests |awk -F: '{print $1}'`; do
- #LC_ALL=${GAWKLOCALE:-C} LANG=${GAWKLOCALE:-C}
+ unset LANG
srcdir=`pwd` AWKPROG=gawk AWK=gawk CMP=cmp make -f Maketests $i >$i.tmp 2>&1
if [ -e _$i ]; then
cat _$i
diff --git a/meta/recipes-extended/gawk/gawk_5.1.1.bb
b/meta/recipes-extended/gawk/gawk_5.2.1.bb
similarity index 86%
rename from meta/recipes-extended/gawk/gawk_5.1.1.bb
rename to meta/recipes-extended/gawk/gawk_5.2.1.bb
index fe339805d0..fbe6e7040b 100644
--- a/meta/recipes-extended/gawk/gawk_5.1.1.bb
+++ b/meta/recipes-extended/gawk/gawk_5.2.1.bb
@@ -20,13 +20,16 @@ SRC_URI = "${GNU_MIRROR}/gawk/gawk-${PV}.tar.gz \
file://run-ptest \
"
-SRC_URI[sha256sum] =
"6168d8d1dc8f74bd17d9dc22fa9634c49070f232343b744901da15fb4f06bffd"
+SRC_URI[sha256sum] =
"529e7c8c6acf21ff3a6183f4d763c632810908989c24675c77995d51ac37b79c"
inherit autotools gettext texinfo update-alternatives
FILES:${PN} += "${datadir}/awk"
FILES:${PN}-dev += "${libdir}/${BPN}/*.la"
+PACKAGES =+ "${PN}-gawkbug"
+FILES:${PN}-gawkbug += "${bindir}/gawkbug"
+
ALTERNATIVE:${PN} = "awk"
ALTERNATIVE_TARGET[awk] = "${bindir}/gawk"
ALTERNATIVE_PRIORITY = "100"
@@ -34,6 +37,8 @@ ALTERNATIVE_PRIORITY = "100"
do_install:append() {
# remove the link since we don't package it
rm ${D}${bindir}/awk
+ # Strip non-reproducible build flags (containing build paths)
+ sed -i -e 's|^CC.*|CC=""|g' -e 's|^CFLAGS.*|CFLAGS=""|g'
${D}${bindir}/gawkbug
}
inherit ptest
@@ -46,7 +51,7 @@ do_install_ptest() {
for i in $TESTS Maketests inclib.awk; do
cp ${S}/test/$i* ${D}${PTEST_PATH}/test
done
- sed -i -e 's|/usr/local/bin|${bindir}|g' \
+ sed -i \
-e 's|#!${ba
[OE-core] [master][PATCH v3] tiff: Security fix for CVE-2022-3970
This patch contains a fix for CVE-2022-3970
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2022-3970
https://security-tracker.debian.org/tracker/CVE-2022-3970
Patch generated from :
https://gitlab.com/libtiff/libtiff/-/commit/227500897dfb07fb7d27f7aa570050e62617e3be
Upstream-Status: Accepted
Signed-off-by: Zheng Qiu
---
.../libtiff/files/CVE-2022-3970.patch | 38 +++
meta/recipes-multimedia/libtiff/tiff_4.4.0.bb | 1 +
2 files changed, 39 insertions(+)
create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2022-3970.patch
diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2022-3970.patch
b/meta/recipes-multimedia/libtiff/files/CVE-2022-3970.patch
new file mode 100644
index 00..e8f143933a
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/files/CVE-2022-3970.patch
@@ -0,0 +1,38 @@
+From 227500897dfb07fb7d27f7aa570050e62617e3be Mon Sep 17 00:00:00 2001
+From: Even Rouault
+Date: Tue, 8 Nov 2022 15:16:58 +0100
+Subject: [PATCH] TIFFReadRGBATileExt(): fix (unsigned) integer overflow on
+ strips/tiles > 2 GB
+
+Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53137
+---
+ libtiff/tif_getimage.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/libtiff/tif_getimage.c b/libtiff/tif_getimage.c
+index a4d0c1d6..60b94d8e 100644
+--- a/libtiff/tif_getimage.c
b/libtiff/tif_getimage.c
+@@ -3016,15 +3016,15 @@ TIFFReadRGBATileExt(TIFF* tif, uint32_t col, uint32_t
row, uint32_t * raster, in
+ return( ok );
+
+ for( i_row = 0; i_row < read_ysize; i_row++ ) {
+-memmove( raster + (tile_ysize - i_row - 1) * tile_xsize,
+- raster + (read_ysize - i_row - 1) * read_xsize,
++memmove( raster + (size_t)(tile_ysize - i_row - 1) * tile_xsize,
++ raster + (size_t)(read_ysize - i_row - 1) * read_xsize,
+ read_xsize * sizeof(uint32_t) );
+-_TIFFmemset( raster + (tile_ysize - i_row - 1) *
tile_xsize+read_xsize,
++_TIFFmemset( raster + (size_t)(tile_ysize - i_row - 1) *
tile_xsize+read_xsize,
+ 0, sizeof(uint32_t) * (tile_xsize - read_xsize) );
+ }
+
+ for( i_row = read_ysize; i_row < tile_ysize; i_row++ ) {
+-_TIFFmemset( raster + (tile_ysize - i_row - 1) * tile_xsize,
++_TIFFmemset( raster + (size_t)(tile_ysize - i_row - 1) * tile_xsize,
+ 0, sizeof(uint32_t) * tile_xsize );
+ }
+
+--
+2.33.0
+
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.4.0.bb
b/meta/recipes-multimedia/libtiff/tiff_4.4.0.bb
index 29cb4111d6..970aab5433 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.4.0.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.4.0.bb
@@ -12,6 +12,7 @@ SRC_URI =
"http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
file://0001-fix-the-FPE-in-tiffcrop-415-427-and-428.patch \
file://CVE-2022-34526.patch \
file://CVE-2022-2953.patch \
+ file://CVE-2022-3970.patch \
file://0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch \
file://0001-tiffcrop-S-option-Make-decision-simpler.patch \
file://0001-tiffcrop-disable-incompatibility-of-Z-X-Y-z-options-.patch \
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173783):
https://lists.openembedded.org/g/openembedded-core/message/173783
Mute This Topic: https://lists.openembedded.org/mt/95258703/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][kirkstone][PATCH] grub2: backport patch to fix CVE-2022-2601 CVE-2022-3775
On Tue, Nov 22, 2022 at 8:08 PM Xiangyu Chen
wrote:
>
> Backport patch from upstream to solve CVE-2022-2601 CVE-2022-3775 dependency:
> font: Fix size overflow in grub_font_get_glyph_internal()
> (https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9c76ec09ae08155df27cd237eaea150b4f02f532)
>
> Backport patch from upstream to fix following CVEs:
> CVE-2022-2601: font: Fix several integer overflows in
> grub_font_construct_glyph()
> (https://git.savannah.gnu.org/cgit/grub.git/commit/?id=768e1ef2fc159f6e14e7246e4be09363708ac39e)
> CVE-2022-3775: font: Fix an integer underflow in blit_comb()
> (https://git.savannah.gnu.org/cgit/grub.git/commit/?id=992c06191babc1e109caf40d6a07ec6fdef427af)
>
> Signed-off-by: Xiangyu Chen
> ---
> ...erflow-in-grub_font_get_glyph_intern.patch | 117 ++
This patch doesn't apply cleanly, please submit a V2
WARNING: grub-2.06-r0 do_patch: Fuzz detected:
Applying patch 0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
patching file grub-core/font/font.c
Hunk #2 succeeded at 767 (offset -2 lines).
patching file include/grub/bitmap.h
Hunk #1 succeeded at 23 with fuzz 2.
Hunk #2 succeeded at 80 (offset -2 lines).
patching file include/grub/safemath.h
Hunk #1 succeeded at 30 with fuzz 2.
The context lines in the patches can be updated with devtool:
devtool modify grub
devtool finish --force-patch-refresh grub
Don't forget to review changes done by devtool!
WARNING: grub-2.06-r0 do_patch: QA Issue: Patch log indicates that
patches do not apply cleanly. [patch-fuzz]
Steve
> .../grub/files/CVE-2022-2601.patch| 87 +
> .../grub/files/CVE-2022-3775.patch| 97 +++
> meta/recipes-bsp/grub/grub2.inc | 3 +
> 4 files changed, 304 insertions(+)
> create mode 100644
> meta/recipes-bsp/grub/files/0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
> create mode 100644 meta/recipes-bsp/grub/files/CVE-2022-2601.patch
> create mode 100644 meta/recipes-bsp/grub/files/CVE-2022-3775.patch
>
> diff --git
> a/meta/recipes-bsp/grub/files/0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
>
> b/meta/recipes-bsp/grub/files/0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
> new file mode 100644
> index 00..db0fff94d2
> --- /dev/null
> +++
> b/meta/recipes-bsp/grub/files/0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
> @@ -0,0 +1,117 @@
> +From 9c76ec09ae08155df27cd237eaea150b4f02f532 Mon Sep 17 00:00:00 2001
> +From: Zhang Boyang
> +Date: Fri, 5 Aug 2022 00:51:20 +0800
> +Subject: [PATCH] font: Fix size overflow in grub_font_get_glyph_internal()
> +
> +The length of memory allocation and file read may overflow. This patch
> +fixes the problem by using safemath macros.
> +
> +There is a lot of code repetition like "(x * y + 7) / 8". It is unsafe
> +if overflow happens. This patch introduces
> grub_video_bitmap_calc_1bpp_bufsz().
> +It is safe replacement for such code. It has safemath-like prototype.
> +
> +This patch also introduces grub_cast(value, pointer), it casts value to
> +typeof(*pointer) then store the value to *pointer. It returns true when
> +overflow occurs or false if there is no overflow. The semantics of arguments
> +and return value are designed to be consistent with other safemath macros.
> +
> +Signed-off-by: Zhang Boyang
> +Reviewed-by: Daniel Kiper
> +
> +Upstream-Status: Backport from
> +[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9c76ec09ae08155df27cd237eaea150b4f02f532]
> +
> +Signed-off-by: Xiangyu Chen
> +---
> + grub-core/font/font.c | 17 +
> + include/grub/bitmap.h | 18 ++
> + include/grub/safemath.h | 2 ++
> + 3 files changed, 33 insertions(+), 4 deletions(-)
> +
> +diff --git a/grub-core/font/font.c b/grub-core/font/font.c
> +index 756ca0abf..e781521a7 100644
> +--- a/grub-core/font/font.c
> b/grub-core/font/font.c
> +@@ -739,7 +739,8 @@ grub_font_get_glyph_internal (grub_font_t font,
> grub_uint32_t code)
> + grub_int16_t xoff;
> + grub_int16_t yoff;
> + grub_int16_t dwidth;
> +- int len;
> ++ grub_ssize_t len;
> ++ grub_size_t sz;
> +
> + if (index_entry->glyph)
> + /* Return cached glyph. */
> +@@ -768,9 +769,17 @@ grub_font_get_glyph_internal (grub_font_t font,
> grub_uint32_t code)
> + return 0;
> + }
> +
> +- len = (width * height + 7) / 8;
> +- glyph = grub_malloc (sizeof (struct grub_font_glyph) + len);
> +- if (!glyph)
> ++ /* Calculate real struct size of current glyph. */
> ++ if (grub_video_bitmap_calc_1bpp_bufsz (width, height, &len) ||
> ++grub_add (sizeof (struct grub_font_glyph), len, &sz))
> ++ {
> ++remove_font (font);
> ++return 0;
> ++ }
> ++
> ++ /* Allocate and initialize the glyph struct. */
> ++ glyph = grub_malloc (sz);
> ++ if (glyph == NULL)
> + {
> + remove_fon
Re: [oe-core][kirkstone][PATCH 1/1] xserver-xorg: fix CVE-2022-3550, CVE-2022-3551
On Fri, Nov 25, 2022 at 6:44 AM Soumya wrote:
>
> A vulnerability classified as critical was found in X.org Server. Affected
> by this vulnerability is the function _GetCountedString of the file
> xkb/xkb.c. The manipulation leads to buffer overflow. It is recommended to
> apply a patch to fix this issue. The associated identifier of this
> vulnerability is VDB-211051.
>
> A vulnerability, which was classified as problematic, has been found in
> X.org Server. Affected by this issue is the function ProcXkbGetKbdByName
> of the file xkb/xkb.c. The manipulation leads to memory leak. It is
> recommended to apply a patch to fix this issue. The identifier of this
> vulnerability is VDB-211052.
>
> References:
> https://nvd.nist.gov/vuln/detail/CVE-2022-3550
> https://nvd.nist.gov/vuln/detail/CVE-2022-3551
>
> Upstream patches:
> https://gitlab.freedesktop.org/xorg/xserver/commit/11beef0b7f1ed290348e45618e5fa0d2bffcb72e
> https://gitlab.freedesktop.org/xorg/xserver/commit/18f91b950e22c2a342a4fbc55e9ddf7534a707d2
>
> Signed-off-by: Soumya
> ---
> ...possible-memleaks-in-XkbGetKbdByName.patch | 63 +++
> ...ntedString-against-request-length-at.patch | 38 +++
> 2 files changed, 101 insertions(+)
> create mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
> create mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-proof-GetCountedString-against-request-length-at.patch
You forgot to add the patches to the recipe!
Steve
>
> diff --git
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
>
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
> new file mode 100644
> index 00..0e61ec5953
> --- /dev/null
> +++
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
> @@ -0,0 +1,63 @@
> +CVE: CVE-2022-3551
> +Upstream-Status: Backport
> +Signed-off-by: Ross Burton
> +
> +From 18f91b950e22c2a342a4fbc55e9ddf7534a707d2 Mon Sep 17 00:00:00 2001
> +From: Peter Hutterer
> +Date: Wed, 13 Jul 2022 11:23:09 +1000
> +Subject: [PATCH] xkb: fix some possible memleaks in XkbGetKbdByName
> +
> +GetComponentByName returns an allocated string, so let's free that if we
> +fail somewhere.
> +
> +Signed-off-by: Peter Hutterer
> +---
> + xkb/xkb.c | 26 --
> + 1 file changed, 20 insertions(+), 6 deletions(-)
> +
> +diff --git a/xkb/xkb.c b/xkb/xkb.c
> +index 4692895db..b79a269e3 100644
> +--- a/xkb/xkb.c
> b/xkb/xkb.c
> +@@ -5935,18 +5935,32 @@ ProcXkbGetKbdByName(ClientPtr client)
> + xkb = dev->key->xkbInfo->desc;
> + status = Success;
> + str = (unsigned char *) &stuff[1];
> +-if (GetComponentSpec(&str, TRUE, &status)) /* keymap, unsupported */
> +-return BadMatch;
> ++{
> ++char *keymap = GetComponentSpec(&str, TRUE, &status); /* keymap,
> unsupported */
> ++if (keymap) {
> ++free(keymap);
> ++return BadMatch;
> ++}
> ++}
> + names.keycodes = GetComponentSpec(&str, TRUE, &status);
> + names.types = GetComponentSpec(&str, TRUE, &status);
> + names.compat = GetComponentSpec(&str, TRUE, &status);
> + names.symbols = GetComponentSpec(&str, TRUE, &status);
> + names.geometry = GetComponentSpec(&str, TRUE, &status);
> +-if (status != Success)
> ++if (status == Success) {
> ++len = str - ((unsigned char *) stuff);
> ++if ((XkbPaddedSize(len) / 4) != stuff->length)
> ++status = BadLength;
> ++}
> ++
> ++if (status != Success) {
> ++free(names.keycodes);
> ++free(names.types);
> ++free(names.compat);
> ++free(names.symbols);
> ++free(names.geometry);
> + return status;
> +-len = str - ((unsigned char *) stuff);
> +-if ((XkbPaddedSize(len) / 4) != stuff->length)
> +-return BadLength;
> ++}
> +
> + CHK_MASK_LEGAL(0x01, stuff->want, XkbGBN_AllComponentsMask);
> + CHK_MASK_LEGAL(0x02, stuff->need, XkbGBN_AllComponentsMask);
> +--
> +2.34.1
> +
> diff --git
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-proof-GetCountedString-against-request-length-at.patch
>
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-proof-GetCountedString-against-request-length-at.patch
> new file mode 100644
> index 00..6f862e82f9
> --- /dev/null
> +++
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-proof-GetCountedString-against-request-length-at.patch
> @@ -0,0 +1,38 @@
> +CVE: CVE-2022-3550
> +Upstream-Status: Backport
> +Signed-off-by: Ross Burton
> +
> +From 11beef0b7f1ed290348e45618e5fa0d2bffcb72e Mon Sep 17 00:00:00 2001
> +From: Peter Hutterer
> +Date: Tue, 5 Jul 2022 12:06:20 +1000
> +Subject: [PATCH] xkb: proof GetCountedString against request length attac
Re: [OE-core][dunfell][PATCH v2] python3: fix CVE-2022-42919 local privilege escalation via the multiprocessing forkserver start method
Hi Steve,
This patch was sent in error to dunfell, Please consider the patch sent for
Kirkstone.
Kind regards,
Vivek
On Fri, 25 Nov 2022 at 10:26 PM, Steve Sakoman wrote:
> On Thu, Nov 24, 2022 at 2:25 AM vkumbhar wrote:
> >
> > From: Vivek Kumbhar
> >
> > Upstream-Status: Backport from
> https://github.com/python/cpython/commit/eae692eed18892309bcc25a2c0f8980038305ea2
> >
> > Signed-off-by: Vivek Kumbhar
> > ---
> > .../python/python3/CVE-2022-42919.patch | 70 +++
> > .../recipes-devtools/python/python3_3.10.7.bb | 1 +
>
> Dunfell python version is 3.8.14, so this patch will not apply. This
> seems to be the same as the patch you sent for kirkstone. Was this
> sent in error?
>
> Steve
>
> > 2 files changed, 71 insertions(+)
> > create mode 100644
> meta/recipes-devtools/python/python3/CVE-2022-42919.patch
> >
> > diff --git a/meta/recipes-devtools/python/python3/CVE-2022-42919.patch
> b/meta/recipes-devtools/python/python3/CVE-2022-42919.patch
> > new file mode 100644
> > index 00..6040724dae
> > --- /dev/null
> > +++ b/meta/recipes-devtools/python/python3/CVE-2022-42919.patch
> > @@ -0,0 +1,70 @@
> > +From 87ef80926ea0ec960a220af89d8ff4db99417b03 Mon Sep 17 00:00:00 2001
> > +From: Vivek Kumbhar
> > +Date: Thu, 24 Nov 2022 17:44:18 +0530
> > +Subject: [PATCH] CVE-2022-42919
> > +
> > +Upstream-Status: Backport [
> https://github.com/python/cpython/commit/eae692eed18892309bcc25a2c0f8980038305ea2
> ]
> > +CVE: CVE-2022-42919
> > +Signed-off-by: Vivek Kumbhar
> > +
> > +[3.10] gh-97514: Don't use Linux abstract sockets for multiprocessing
> (GH-98501) (GH-98503)
> > +
> > +Linux abstract sockets are insecure as they lack any form of filesystem
> > +permissions so their use allows anyone on the system to inject code into
> > +the process.
> > +
> > +This removes the default preference for abstract sockets in
> > +multiprocessing introduced in Python 3.9+ via
> > +https://github.com/python/cpython/pull/18866 while fixing
> > +https://github.com/python/cpython/issues/84031.
> > +
> > +Explicit use of an abstract socket by a user now generates a
> > +RuntimeWarning. If we choose to keep this warning, it should be
> > +backported to the 3.7 and 3.8 branches.
> > +(cherry picked from commit 49f61068f49747164988ffc5a442d2a63874fc17)
> > +---
> > + Lib/multiprocessing/connection.py | 5 -
> > + .../2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst | 15 +++
> > + 2 files changed, 15 insertions(+), 5 deletions(-)
> > + create mode 100644
> Misc/NEWS.d/next/Security/2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst
> > +
> > +diff --git a/Lib/multiprocessing/connection.py
> b/Lib/multiprocessing/connection.py
> > +index 510e4b5..8e2facf 100644
> > +--- a/Lib/multiprocessing/connection.py
> > b/Lib/multiprocessing/connection.py
> > +@@ -73,11 +73,6 @@ def arbitrary_address(family):
> > + if family == 'AF_INET':
> > + return ('localhost', 0)
> > + elif family == 'AF_UNIX':
> > +-# Prefer abstract sockets if possible to avoid problems with
> the address
> > +-# size. When coding portable applications, some
> implementations have
> > +-# sun_path as short as 92 bytes in the sockaddr_un struct.
> > +-if util.abstract_sockets_supported:
> > +-return f"\0listener-{os.getpid()}-{next(_mmap_counter)}"
> > + return tempfile.mktemp(prefix='listener-',
> dir=util.get_temp_dir())
> > + elif family == 'AF_PIPE':
> > + return tempfile.mktemp(prefix=r'\\.\pipe\pyc-%d-%d-' %
> > +diff --git
> a/Misc/NEWS.d/next/Security/2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst
> b/Misc/NEWS.d/next/Security/2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst
> > +new file mode 100644
> > +index 000..02d95b5
> > +--- /dev/null
> >
> b/Misc/NEWS.d/next/Security/2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst
> > +@@ -0,0 +1,15 @@
> > ++On Linux the :mod:`multiprocessing` module returns to using filesystem
> backed
> > ++unix domain sockets for communication with the *forkserver* process
> instead of
> > ++the Linux abstract socket namespace. Only code that chooses to use the
> > ++:ref:`"forkserver" start method ` is
> affected.
> > ++
> > ++Abstract sockets have no permissions and could allow any user on the
> system in
> > ++the same `network namespace
> > ++`_
> (often the
> > ++whole system) to inject code into the multiprocessing *forkserver*
> process.
> > ++This was a potential privilege escalation. Filesystem based socket
> permissions
> > ++restrict this to the *forkserver* process user as was the default in
> Python 3.8
> > ++and earlier.
> > ++
> > ++This prevents Linux `CVE-2022-42919
> > ++`_.
> > +--
> > +2.25.1
> > +
> > diff --git a/meta/recipes-devtools/python/python3_3.10.7.bb
> b/meta/recipes-devtools/python/python3_3.10.7.bb
> > index 404a582135..2
Re: [OE-core] [master][PATCH] tiff: Security fix for CVE-2022-3970
>-Original Message- >From: Ross Burton >Sent: Friday, November 25, 2022 10:50 AM >To: Qiu, Zheng >Cc: Openembedded Core ; >MacLeod, Randy >Subject: Re: [OE-core] [master][PATCH] tiff: Security fix for CVE-2022-3970 > >CAUTION: This email comes from a non Wind River email account! >Do not click links or open attachments unless you recognize the sender and >know the content is safe. > >On 25 Nov 2022, at 15:03, Qiu, Zheng via lists.openembedded.org > wrote: >> >>> On Nov 25, 2022, at 9:54 AM, Ross Burton wrote: >>> >>> master has libtiff 4.4.0 so this doesn’t apply. Is the CVE still valid in >>> that >release, or has it been fixed? >>> >>> Ross >> >> It seems like this CVE is fixed after 4.4.0 to me. > >Can you rebase and resend then? [] I rebased and sent a new patch this Tuesday @ 10:49 AM. Do you still want me to send a new one? ZQ > >Thanks, >Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173779): https://lists.openembedded.org/g/openembedded-core/message/173779 Mute This Topic: https://lists.openembedded.org/mt/9519/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][dunfell][PATCH v2] python3: fix CVE-2022-42919 local privilege escalation via the multiprocessing forkserver start method
On Thu, Nov 24, 2022 at 2:25 AM vkumbhar wrote:
>
> From: Vivek Kumbhar
>
> Upstream-Status: Backport from
> https://github.com/python/cpython/commit/eae692eed18892309bcc25a2c0f8980038305ea2
>
> Signed-off-by: Vivek Kumbhar
> ---
> .../python/python3/CVE-2022-42919.patch | 70 +++
> .../recipes-devtools/python/python3_3.10.7.bb | 1 +
Dunfell python version is 3.8.14, so this patch will not apply. This
seems to be the same as the patch you sent for kirkstone. Was this
sent in error?
Steve
> 2 files changed, 71 insertions(+)
> create mode 100644 meta/recipes-devtools/python/python3/CVE-2022-42919.patch
>
> diff --git a/meta/recipes-devtools/python/python3/CVE-2022-42919.patch
> b/meta/recipes-devtools/python/python3/CVE-2022-42919.patch
> new file mode 100644
> index 00..6040724dae
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3/CVE-2022-42919.patch
> @@ -0,0 +1,70 @@
> +From 87ef80926ea0ec960a220af89d8ff4db99417b03 Mon Sep 17 00:00:00 2001
> +From: Vivek Kumbhar
> +Date: Thu, 24 Nov 2022 17:44:18 +0530
> +Subject: [PATCH] CVE-2022-42919
> +
> +Upstream-Status: Backport
> [https://github.com/python/cpython/commit/eae692eed18892309bcc25a2c0f8980038305ea2]
> +CVE: CVE-2022-42919
> +Signed-off-by: Vivek Kumbhar
> +
> +[3.10] gh-97514: Don't use Linux abstract sockets for multiprocessing
> (GH-98501) (GH-98503)
> +
> +Linux abstract sockets are insecure as they lack any form of filesystem
> +permissions so their use allows anyone on the system to inject code into
> +the process.
> +
> +This removes the default preference for abstract sockets in
> +multiprocessing introduced in Python 3.9+ via
> +https://github.com/python/cpython/pull/18866 while fixing
> +https://github.com/python/cpython/issues/84031.
> +
> +Explicit use of an abstract socket by a user now generates a
> +RuntimeWarning. If we choose to keep this warning, it should be
> +backported to the 3.7 and 3.8 branches.
> +(cherry picked from commit 49f61068f49747164988ffc5a442d2a63874fc17)
> +---
> + Lib/multiprocessing/connection.py | 5 -
> + .../2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst | 15 +++
> + 2 files changed, 15 insertions(+), 5 deletions(-)
> + create mode 100644
> Misc/NEWS.d/next/Security/2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst
> +
> +diff --git a/Lib/multiprocessing/connection.py
> b/Lib/multiprocessing/connection.py
> +index 510e4b5..8e2facf 100644
> +--- a/Lib/multiprocessing/connection.py
> b/Lib/multiprocessing/connection.py
> +@@ -73,11 +73,6 @@ def arbitrary_address(family):
> + if family == 'AF_INET':
> + return ('localhost', 0)
> + elif family == 'AF_UNIX':
> +-# Prefer abstract sockets if possible to avoid problems with the
> address
> +-# size. When coding portable applications, some implementations
> have
> +-# sun_path as short as 92 bytes in the sockaddr_un struct.
> +-if util.abstract_sockets_supported:
> +-return f"\0listener-{os.getpid()}-{next(_mmap_counter)}"
> + return tempfile.mktemp(prefix='listener-', dir=util.get_temp_dir())
> + elif family == 'AF_PIPE':
> + return tempfile.mktemp(prefix=r'\\.\pipe\pyc-%d-%d-' %
> +diff --git
> a/Misc/NEWS.d/next/Security/2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst
> b/Misc/NEWS.d/next/Security/2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst
> +new file mode 100644
> +index 000..02d95b5
> +--- /dev/null
> b/Misc/NEWS.d/next/Security/2022-09-07-10-42-00.gh-issue-97514.Yggdsl.rst
> +@@ -0,0 +1,15 @@
> ++On Linux the :mod:`multiprocessing` module returns to using filesystem
> backed
> ++unix domain sockets for communication with the *forkserver* process instead
> of
> ++the Linux abstract socket namespace. Only code that chooses to use the
> ++:ref:`"forkserver" start method ` is
> affected.
> ++
> ++Abstract sockets have no permissions and could allow any user on the system
> in
> ++the same `network namespace
> ++`_ (often
> the
> ++whole system) to inject code into the multiprocessing *forkserver* process.
> ++This was a potential privilege escalation. Filesystem based socket
> permissions
> ++restrict this to the *forkserver* process user as was the default in Python
> 3.8
> ++and earlier.
> ++
> ++This prevents Linux `CVE-2022-42919
> ++`_.
> +--
> +2.25.1
> +
> diff --git a/meta/recipes-devtools/python/python3_3.10.7.bb
> b/meta/recipes-devtools/python/python3_3.10.7.bb
> index 404a582135..2d230793ef 100644
> --- a/meta/recipes-devtools/python/python3_3.10.7.bb
> +++ b/meta/recipes-devtools/python/python3_3.10.7.bb
> @@ -35,6 +35,7 @@ SRC_URI =
> "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
>
> file://0001-setup.py-Do-not-detect-multiarch-paths-when-cross-co.patch \
> file://deterministic_imports.patch \
[oe-core][kirkstone][PATCH 1/1] xserver-xorg: fix CVE-2022-3550, CVE-2022-3551
A vulnerability classified as critical was found in X.org Server. Affected
by this vulnerability is the function _GetCountedString of the file
xkb/xkb.c. The manipulation leads to buffer overflow. It is recommended to
apply a patch to fix this issue. The associated identifier of this
vulnerability is VDB-211051.
A vulnerability, which was classified as problematic, has been found in
X.org Server. Affected by this issue is the function ProcXkbGetKbdByName
of the file xkb/xkb.c. The manipulation leads to memory leak. It is
recommended to apply a patch to fix this issue. The identifier of this
vulnerability is VDB-211052.
References:
https://nvd.nist.gov/vuln/detail/CVE-2022-3550
https://nvd.nist.gov/vuln/detail/CVE-2022-3551
Upstream patches:
https://gitlab.freedesktop.org/xorg/xserver/commit/11beef0b7f1ed290348e45618e5fa0d2bffcb72e
https://gitlab.freedesktop.org/xorg/xserver/commit/18f91b950e22c2a342a4fbc55e9ddf7534a707d2
Signed-off-by: Soumya
---
...possible-memleaks-in-XkbGetKbdByName.patch | 63 +++
...ntedString-against-request-length-at.patch | 38 +++
2 files changed, 101 insertions(+)
create mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
create mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-proof-GetCountedString-against-request-length-at.patch
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
new file mode 100644
index 00..0e61ec5953
--- /dev/null
+++
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
@@ -0,0 +1,63 @@
+CVE: CVE-2022-3551
+Upstream-Status: Backport
+Signed-off-by: Ross Burton
+
+From 18f91b950e22c2a342a4fbc55e9ddf7534a707d2 Mon Sep 17 00:00:00 2001
+From: Peter Hutterer
+Date: Wed, 13 Jul 2022 11:23:09 +1000
+Subject: [PATCH] xkb: fix some possible memleaks in XkbGetKbdByName
+
+GetComponentByName returns an allocated string, so let's free that if we
+fail somewhere.
+
+Signed-off-by: Peter Hutterer
+---
+ xkb/xkb.c | 26 --
+ 1 file changed, 20 insertions(+), 6 deletions(-)
+
+diff --git a/xkb/xkb.c b/xkb/xkb.c
+index 4692895db..b79a269e3 100644
+--- a/xkb/xkb.c
b/xkb/xkb.c
+@@ -5935,18 +5935,32 @@ ProcXkbGetKbdByName(ClientPtr client)
+ xkb = dev->key->xkbInfo->desc;
+ status = Success;
+ str = (unsigned char *) &stuff[1];
+-if (GetComponentSpec(&str, TRUE, &status)) /* keymap, unsupported */
+-return BadMatch;
++{
++char *keymap = GetComponentSpec(&str, TRUE, &status); /* keymap,
unsupported */
++if (keymap) {
++free(keymap);
++return BadMatch;
++}
++}
+ names.keycodes = GetComponentSpec(&str, TRUE, &status);
+ names.types = GetComponentSpec(&str, TRUE, &status);
+ names.compat = GetComponentSpec(&str, TRUE, &status);
+ names.symbols = GetComponentSpec(&str, TRUE, &status);
+ names.geometry = GetComponentSpec(&str, TRUE, &status);
+-if (status != Success)
++if (status == Success) {
++len = str - ((unsigned char *) stuff);
++if ((XkbPaddedSize(len) / 4) != stuff->length)
++status = BadLength;
++}
++
++if (status != Success) {
++free(names.keycodes);
++free(names.types);
++free(names.compat);
++free(names.symbols);
++free(names.geometry);
+ return status;
+-len = str - ((unsigned char *) stuff);
+-if ((XkbPaddedSize(len) / 4) != stuff->length)
+-return BadLength;
++}
+
+ CHK_MASK_LEGAL(0x01, stuff->want, XkbGBN_AllComponentsMask);
+ CHK_MASK_LEGAL(0x02, stuff->need, XkbGBN_AllComponentsMask);
+--
+2.34.1
+
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-proof-GetCountedString-against-request-length-at.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-proof-GetCountedString-against-request-length-at.patch
new file mode 100644
index 00..6f862e82f9
--- /dev/null
+++
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-proof-GetCountedString-against-request-length-at.patch
@@ -0,0 +1,38 @@
+CVE: CVE-2022-3550
+Upstream-Status: Backport
+Signed-off-by: Ross Burton
+
+From 11beef0b7f1ed290348e45618e5fa0d2bffcb72e Mon Sep 17 00:00:00 2001
+From: Peter Hutterer
+Date: Tue, 5 Jul 2022 12:06:20 +1000
+Subject: [PATCH] xkb: proof GetCountedString against request length attacks
+
+GetCountedString did a check for the whole string to be within the
+request buffer but not for the initial 2 bytes that contain the length
+field. A swapped client could send a malformed request to trigger a
+swaps() on those bytes, writing into random memory.
+
+Signed-off-by: Peter Hutterer
+---
+ xkb/xkb.c | 5 +
+ 1 file cha
Re: [OE-core] [PATCH] linux-yocto: enable strict kernel module signing by default
On 25/11/2022 15:54, Mikko Rapeli wrote:
> It's a good default and used in many Linux distributions.
> Did not test out of tree modules if they do correct things but
> any such failures should be fixed.
>
> One way to verify that kernel module signing also works:
>
> root@qemux86-64:~# dmesg|grep X.509
> [1.298936] Loading compiled-in X.509 certificates
> [1.328280] Loaded X.509 cert 'Build time autogenerated kernel key:
> ee1bed6d845358744c764683bf73b4404cc79287'
>
> These logs in dmesg show that signing in kernel is enabled and
> key is found. Then if any kernel modules load, they were
> signed correctly. Additionally modinfo tool from kmod shows kernel module
> signing details:
Hi Mikko,
Do the kernel modules get properly stripped, last time I was looking at
this it was skipped when signed and as such root filesystem sizes
ballooned with signed modules.
Regards,
Jack.
>
> root@qemux86-64:~# lsmod
> Module Size Used by
> sch_fq_codel 20480 1
> root@qemux86-64:~# modinfo sch_fq_codel
> filename:
> /lib/modules/5.19.9-yocto-standard/kernel/net/sched/sch_fq_codel.ko
> description:Fair Queue CoDel discipline
> license:GPL
> author: Eric Dumazet
> depends:
> retpoline: Y
> intree: Y
> name: sch_fq_codel
> vermagic: 5.19.9-yocto-standard SMP preempt mod_unload
> sig_id: PKCS#7
> signer: Build time autogenerated kernel key
> sig_key:2B:2A:BE:7D:B5:92:DC:98:A9:F8:D7:00:A6:73:35:20:10:D8:19:EE
> sig_hashalgo: sha512
> signature: 72:6C:E1:78:7C:A7:7B:CC:C4:33:23:6B:95:EC:1B:2A:BD:D9:EC:7A:
> 85:07:05:B2:70:3C:C9:64:F6:78:8A:01:A0:E3:64:C7:47:BB:5D:0E:
> 86:BA:C1:DD:40:05:AE:1F:19:D4:F0:98:49:86:CC:61:14:3C:AB:1E:
> 4A:1C:83:47:1D:FA:6D:E4:83:79:3A:2B:3F:7D:B6:E0:09:AE:B4:01:
> 07:EE:C9:5B:99:70:4F:49:8A:64:E4:7D:84:AA:37:F5:DB:5F:16:5C:
> D4:DC:0C:33:73:5D:D9:8D:7E:71:5B:A1:ED:61:81:5E:1C:ED:A2:D8:
> 76:46:99:B3:78:08:F7:7F:0D:4B:94:26:21:63:47:B0:75:9F:A4:EA:
> 3D:14:D4:09:CC:59:F3:FC:80:AC:BF:56:1E:8C:73:FD:CB:07:27:C6:
> 3D:98:4C:E4:C3:9C:C0:AD:90:53:46:8F:AE:66:FE:10:C8:92:7F:BA:
> 74:C2:B0:E3:6E:47:66:AB:39:25:41:12:66:91:20:27:1A:58:77:75:
> 4F:C0:3F:F1:8E:5F:AB:0A:BD:8B:62:4F:2B:01:5A:5C:4E:5C:31:39:
> FB:F4:14:2E:BF:D8:51:4B:C8:D0:E2:0A:20:80:95:05:80:E3:46:75:
> 43:80:30:63:6F:A4:25:82:59:35:34:E8:6A:DC:FF:93:F8:32:BB:FA:
> 66:2D:B9:08:75:1A:3A:3A:5D:57:F4:63:85:01:B4:EB:96:1B:CE:6F:
> 4D:61:FC:AA:6C:39:7F:D6:37:C9:84:0A:84:17:FB:BE:FC:20:CB:EE:
> 8C:2F:93:92:F6:48:F4:07:50:84:D8:2C:B5:2E:A7:7D:3A:3F:DC:E9:
> B9:17:EF:47:49:EC:BA:62:1C:C4:C6:58:9C:0C:8D:26:41:6E:1F:C1:
> 95:A7:8B:57:5D:1D:4B:B4:04:00:F6:68:24:9E:E2:BF:11:EC:05:6C:
> 83:E8:C6:DB:BB:3D:22:8B:31:BB:99:1A:44:E1:15:71:C3:AA:FA:01:
> 98:BA:6B:20:26:D6:9C:61:5C:6F:81:29:09:B1:EA:C5:28:15:F3:98:
> C0:18:FE:08:8B:40:A5:F3:3C:71:4B:C6:41:CD:38:51:79:EA:5D:C9:
> 13:39:B5:FD:A3:D1:BB:11:94:66:F7:7B:6A:DC:2C:01:5F:AB:73:08:
> 68:24:32:BE:BC:7A:90:E5:FD:97:17:6C:DD:46:D0:0E:2C:03:31:66:
> B3:7C:B2:48:E1:E0:1A:63:20:48:4C:D4:55:56:71:04:3B:5F:3B:28:
> BF:64:6C:52:A9:07:6D:FF:21:E9:06:35:E8:A1:D7:F4:C2:F9:D7:7B:
> 9D:D2:90:16:2F:68:1E:3F:BE:43:ED:64
>
> Failures in signed kernel module loading should show as errors at
> runtime, for example systemd services, or as oeqa parselogs test
> failures which detects signature verification error messages from the
> kernel.
>
> Signed-off-by: Mikko Rapeli
> ---
> meta/recipes-kernel/linux/linux-yocto.inc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 091003ed82..bab1f21479 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -37,6 +37,9 @@ KERNEL_FEATURES:append = "
> ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/
> KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa',
> 'features/numa/numa.scc', '', d)}"
> KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat',
> 'cfg/fs/vfat.scc', '', d)}"
>
> +# enable module signing by default
> +KERNEL_FEATURES:append = " features/module-signing/force-signing.scc"
> +
> # A KMACHINE is the mapping of a yocto $MACHINE to what is built
> # by the kernel. This is typically the branch that should be built,
> # and it can be specific to the machine or shared
>
>
>
>
>
--
Jack Mitchell, Consultant
https://www.tuxable.co.uk
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173776):
ht
Re: [OE-core] [PATCH] linux-yocto: enable strict kernel module signing by default
Hi,
On Fri, Nov 25, 2022 at 05:54:12PM +0200, Mikko Rapeli wrote:
> It's a good default and used in many Linux distributions.
> Did not test out of tree modules if they do correct things but
> any such failures should be fixed.
When testing this I saw some odd results and cert verification
failures at runtime. I suspect it was just me and I did not take
into account how kernel and rootfs get deployed while rebuilding
the changes and can't reproduce any errors with this now.
But if this exposes any issues, then those would need to be fixed too.
I think this is a good default.
Cheers,
-Mikko
> One way to verify that kernel module signing also works:
>
> root@qemux86-64:~# dmesg|grep X.509
> [1.298936] Loading compiled-in X.509 certificates
> [1.328280] Loaded X.509 cert 'Build time autogenerated kernel key:
> ee1bed6d845358744c764683bf73b4404cc79287'
>
> These logs in dmesg show that signing in kernel is enabled and
> key is found. Then if any kernel modules load, they were
> signed correctly. Additionally modinfo tool from kmod shows kernel module
> signing details:
>
> root@qemux86-64:~# lsmod
> Module Size Used by
> sch_fq_codel 20480 1
> root@qemux86-64:~# modinfo sch_fq_codel
> filename:
> /lib/modules/5.19.9-yocto-standard/kernel/net/sched/sch_fq_codel.ko
> description:Fair Queue CoDel discipline
> license:GPL
> author: Eric Dumazet
> depends:
> retpoline: Y
> intree: Y
> name: sch_fq_codel
> vermagic: 5.19.9-yocto-standard SMP preempt mod_unload
> sig_id: PKCS#7
> signer: Build time autogenerated kernel key
> sig_key:2B:2A:BE:7D:B5:92:DC:98:A9:F8:D7:00:A6:73:35:20:10:D8:19:EE
> sig_hashalgo: sha512
> signature: 72:6C:E1:78:7C:A7:7B:CC:C4:33:23:6B:95:EC:1B:2A:BD:D9:EC:7A:
> 85:07:05:B2:70:3C:C9:64:F6:78:8A:01:A0:E3:64:C7:47:BB:5D:0E:
> 86:BA:C1:DD:40:05:AE:1F:19:D4:F0:98:49:86:CC:61:14:3C:AB:1E:
> 4A:1C:83:47:1D:FA:6D:E4:83:79:3A:2B:3F:7D:B6:E0:09:AE:B4:01:
> 07:EE:C9:5B:99:70:4F:49:8A:64:E4:7D:84:AA:37:F5:DB:5F:16:5C:
> D4:DC:0C:33:73:5D:D9:8D:7E:71:5B:A1:ED:61:81:5E:1C:ED:A2:D8:
> 76:46:99:B3:78:08:F7:7F:0D:4B:94:26:21:63:47:B0:75:9F:A4:EA:
> 3D:14:D4:09:CC:59:F3:FC:80:AC:BF:56:1E:8C:73:FD:CB:07:27:C6:
> 3D:98:4C:E4:C3:9C:C0:AD:90:53:46:8F:AE:66:FE:10:C8:92:7F:BA:
> 74:C2:B0:E3:6E:47:66:AB:39:25:41:12:66:91:20:27:1A:58:77:75:
> 4F:C0:3F:F1:8E:5F:AB:0A:BD:8B:62:4F:2B:01:5A:5C:4E:5C:31:39:
> FB:F4:14:2E:BF:D8:51:4B:C8:D0:E2:0A:20:80:95:05:80:E3:46:75:
> 43:80:30:63:6F:A4:25:82:59:35:34:E8:6A:DC:FF:93:F8:32:BB:FA:
> 66:2D:B9:08:75:1A:3A:3A:5D:57:F4:63:85:01:B4:EB:96:1B:CE:6F:
> 4D:61:FC:AA:6C:39:7F:D6:37:C9:84:0A:84:17:FB:BE:FC:20:CB:EE:
> 8C:2F:93:92:F6:48:F4:07:50:84:D8:2C:B5:2E:A7:7D:3A:3F:DC:E9:
> B9:17:EF:47:49:EC:BA:62:1C:C4:C6:58:9C:0C:8D:26:41:6E:1F:C1:
> 95:A7:8B:57:5D:1D:4B:B4:04:00:F6:68:24:9E:E2:BF:11:EC:05:6C:
> 83:E8:C6:DB:BB:3D:22:8B:31:BB:99:1A:44:E1:15:71:C3:AA:FA:01:
> 98:BA:6B:20:26:D6:9C:61:5C:6F:81:29:09:B1:EA:C5:28:15:F3:98:
> C0:18:FE:08:8B:40:A5:F3:3C:71:4B:C6:41:CD:38:51:79:EA:5D:C9:
> 13:39:B5:FD:A3:D1:BB:11:94:66:F7:7B:6A:DC:2C:01:5F:AB:73:08:
> 68:24:32:BE:BC:7A:90:E5:FD:97:17:6C:DD:46:D0:0E:2C:03:31:66:
> B3:7C:B2:48:E1:E0:1A:63:20:48:4C:D4:55:56:71:04:3B:5F:3B:28:
> BF:64:6C:52:A9:07:6D:FF:21:E9:06:35:E8:A1:D7:F4:C2:F9:D7:7B:
> 9D:D2:90:16:2F:68:1E:3F:BE:43:ED:64
>
> Failures in signed kernel module loading should show as errors at
> runtime, for example systemd services, or as oeqa parselogs test
> failures which detects signature verification error messages from the
> kernel.
>
> Signed-off-by: Mikko Rapeli
> ---
> meta/recipes-kernel/linux/linux-yocto.inc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 091003ed82..bab1f21479 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -37,6 +37,9 @@ KERNEL_FEATURES:append = "
> ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/
> KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa',
> 'features/numa/numa.scc', '', d)}"
> KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat',
> 'cfg/fs/vfat.scc', '', d)}"
>
> +# enable module signing by default
> +KERNEL_FEATURES:append = " features/module-signing/force-signing.scc"
> +
> # A KMACHINE is the mapping of a yocto $MACHINE to what is built
> # by the kernel. This is typically the branch that should be built,
> # and it can be specific to the
[OE-core] [PATCH] linux-yocto: enable strict kernel module signing by default
It's a good default and used in many Linux distributions.
Did not test out of tree modules if they do correct things but
any such failures should be fixed.
One way to verify that kernel module signing also works:
root@qemux86-64:~# dmesg|grep X.509
[1.298936] Loading compiled-in X.509 certificates
[1.328280] Loaded X.509 cert 'Build time autogenerated kernel key:
ee1bed6d845358744c764683bf73b4404cc79287'
These logs in dmesg show that signing in kernel is enabled and
key is found. Then if any kernel modules load, they were
signed correctly. Additionally modinfo tool from kmod shows kernel module
signing details:
root@qemux86-64:~# lsmod
Module Size Used by
sch_fq_codel 20480 1
root@qemux86-64:~# modinfo sch_fq_codel
filename:
/lib/modules/5.19.9-yocto-standard/kernel/net/sched/sch_fq_codel.ko
description:Fair Queue CoDel discipline
license:GPL
author: Eric Dumazet
depends:
retpoline: Y
intree: Y
name: sch_fq_codel
vermagic: 5.19.9-yocto-standard SMP preempt mod_unload
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key:2B:2A:BE:7D:B5:92:DC:98:A9:F8:D7:00:A6:73:35:20:10:D8:19:EE
sig_hashalgo: sha512
signature: 72:6C:E1:78:7C:A7:7B:CC:C4:33:23:6B:95:EC:1B:2A:BD:D9:EC:7A:
85:07:05:B2:70:3C:C9:64:F6:78:8A:01:A0:E3:64:C7:47:BB:5D:0E:
86:BA:C1:DD:40:05:AE:1F:19:D4:F0:98:49:86:CC:61:14:3C:AB:1E:
4A:1C:83:47:1D:FA:6D:E4:83:79:3A:2B:3F:7D:B6:E0:09:AE:B4:01:
07:EE:C9:5B:99:70:4F:49:8A:64:E4:7D:84:AA:37:F5:DB:5F:16:5C:
D4:DC:0C:33:73:5D:D9:8D:7E:71:5B:A1:ED:61:81:5E:1C:ED:A2:D8:
76:46:99:B3:78:08:F7:7F:0D:4B:94:26:21:63:47:B0:75:9F:A4:EA:
3D:14:D4:09:CC:59:F3:FC:80:AC:BF:56:1E:8C:73:FD:CB:07:27:C6:
3D:98:4C:E4:C3:9C:C0:AD:90:53:46:8F:AE:66:FE:10:C8:92:7F:BA:
74:C2:B0:E3:6E:47:66:AB:39:25:41:12:66:91:20:27:1A:58:77:75:
4F:C0:3F:F1:8E:5F:AB:0A:BD:8B:62:4F:2B:01:5A:5C:4E:5C:31:39:
FB:F4:14:2E:BF:D8:51:4B:C8:D0:E2:0A:20:80:95:05:80:E3:46:75:
43:80:30:63:6F:A4:25:82:59:35:34:E8:6A:DC:FF:93:F8:32:BB:FA:
66:2D:B9:08:75:1A:3A:3A:5D:57:F4:63:85:01:B4:EB:96:1B:CE:6F:
4D:61:FC:AA:6C:39:7F:D6:37:C9:84:0A:84:17:FB:BE:FC:20:CB:EE:
8C:2F:93:92:F6:48:F4:07:50:84:D8:2C:B5:2E:A7:7D:3A:3F:DC:E9:
B9:17:EF:47:49:EC:BA:62:1C:C4:C6:58:9C:0C:8D:26:41:6E:1F:C1:
95:A7:8B:57:5D:1D:4B:B4:04:00:F6:68:24:9E:E2:BF:11:EC:05:6C:
83:E8:C6:DB:BB:3D:22:8B:31:BB:99:1A:44:E1:15:71:C3:AA:FA:01:
98:BA:6B:20:26:D6:9C:61:5C:6F:81:29:09:B1:EA:C5:28:15:F3:98:
C0:18:FE:08:8B:40:A5:F3:3C:71:4B:C6:41:CD:38:51:79:EA:5D:C9:
13:39:B5:FD:A3:D1:BB:11:94:66:F7:7B:6A:DC:2C:01:5F:AB:73:08:
68:24:32:BE:BC:7A:90:E5:FD:97:17:6C:DD:46:D0:0E:2C:03:31:66:
B3:7C:B2:48:E1:E0:1A:63:20:48:4C:D4:55:56:71:04:3B:5F:3B:28:
BF:64:6C:52:A9:07:6D:FF:21:E9:06:35:E8:A1:D7:F4:C2:F9:D7:7B:
9D:D2:90:16:2F:68:1E:3F:BE:43:ED:64
Failures in signed kernel module loading should show as errors at
runtime, for example systemd services, or as oeqa parselogs test
failures which detects signature verification error messages from the
kernel.
Signed-off-by: Mikko Rapeli
---
meta/recipes-kernel/linux/linux-yocto.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 091003ed82..bab1f21479 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -37,6 +37,9 @@ KERNEL_FEATURES:append = "
${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/
KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa',
'features/numa/numa.scc', '', d)}"
KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat',
'cfg/fs/vfat.scc', '', d)}"
+# enable module signing by default
+KERNEL_FEATURES:append = " features/module-signing/force-signing.scc"
+
# A KMACHINE is the mapping of a yocto $MACHINE to what is built
# by the kernel. This is typically the branch that should be built,
# and it can be specific to the machine or shared
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173774):
https://lists.openembedded.org/g/openembedded-core/message/173774
Mute This Topic: https://lists.openembedded.org/mt/95256076/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [master][PATCH] tiff: Security fix for CVE-2022-3970
On 25 Nov 2022, at 15:03, Qiu, Zheng via lists.openembedded.org wrote: > >> On Nov 25, 2022, at 9:54 AM, Ross Burton wrote: >> >> master has libtiff 4.4.0 so this doesn’t apply. Is the CVE still valid in >> that release, or has it been fixed? >> >> Ross > > It seems like this CVE is fixed after 4.4.0 to me. Can you rebase and resend then? Thanks, Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173773): https://lists.openembedded.org/g/openembedded-core/message/173773 Mute This Topic: https://lists.openembedded.org/mt/9519/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] kmod: enable openssl support by default
linux-yocto kernel adds openssl-native dependency by default even
when module signing is still optional. kmod should enable
openssl support too. This helps see details of signed kernel
modules and debug issues with module signing. For small systems
this can still be disabled.
modinfo output shows bad signing info when kernel signing is enabled
but openssl support is missing from kmod:
root@qemux86-64:~# dmesg|grep 509
[0.750905] ACPI: PCI: Interrupt link LNKG configured for IRQ 11
[0.950039] Asymmetric key parser 'x509' registered
[1.241727] Loading compiled-in X.509 certificates
[1.267863] Loaded X.509 cert 'Build time autogenerated kernel key:
48bcd79439f61aaf8fc19ec0882439d64db73820'
root@qemux86-64:~# lsmod
Module Size Used by
sch_fq_codel 20480 1
root@qemux86-64:~# modinfo sch_fq_codel
filename:
/lib/modules/5.19.9-yocto-standard/kernel/net/sched/sch_fq_codel.ko
description:Fair Queue CoDel discipline
license:GPL
author: Eric Dumazet
depends:
retpoline: Y
intree: Y
name: sch_fq_codel
vermagic: 5.19.9-yocto-standard SMP preempt mod_unload
sig_id: PKCS#7
signer:
sig_key:
sig_hashalgo: unknown
signature:
modinfo with openssl enabled in kmod:
root@qemux86-64:~# modinfo sch_fq_codel
filename:
/lib/modules/5.19.9-yocto-standard/kernel/net/sched/sch_fq_codel.ko
description:Fair Queue CoDel discipline
license:GPL
author: Eric Dumazet
depends:
retpoline: Y
intree: Y
name: sch_fq_codel
vermagic: 5.19.9-yocto-standard SMP preempt mod_unload
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key:07:9A:C4:36:96:98:6E:5B:73:CF:C8:40:A6:57:D9:03:5E:27:8D:25
sig_hashalgo: sha512
signature: 21:4D:F0:E2:E0:7C:8E:31:A0:96:12:68:06:0D:FA:0D:E2:17:45:64:
51:94:7E:B0:97:DD:EB:59:89:CA:1A:C3:10:E7:7C:4D:5D:F0:5D:B6:
2A:61:D3:BF:89:7A:0D:CD:A2:39:57:1B:C6:B5:7D:C1:DB:6F:D9:36:
29:7A:07:18:F5:22:9F:9A:33:4D:38:BC:79:C8:51:8B:82:0F:B4:09:
08:37:52:11:98:50:7E:19:28:0F:13:2E:03:A5:E8:F8:D9:E7:DF:61:
18:AC:22:FE:96:BD:D0:55:96:9E:C9:1C:15:C9:0B:9A:5A:FD:D0:C0:
8F:41:12:5B:EA:4B:E5:5D:4D:EA:D5:2E:E5:80:D4:51:CC:63:97:F3:
4B:39:CC:B6:A1:83:F5:EF:2F:A1:22:CD:CA:BC:DB:82:C0:E4:AB:13:
5D:C5:F3:BC:B7:3E:B4:16:BF:87:1D:AC:69:43:1F:78:2A:5F:E2:63:
52:A2:DA:FC:F9:C0:BA:D8:1A:FE:58:4E:6A:D8:DE:BE:F8:F6:C2:59:
CE:F5:0A:A0:15:A3:01:BC:B6:70:36:4E:5F:D6:9B:B0:DE:93:15:3E:
35:37:38:D9:01:2B:72:2F:D3:74:A4:AD:F4:5F:52:74:44:E1:C9:D3:
A9:87:BC:93:58:8A:82:DB:14:6F:E0:4D:AF:8E:B5:3D:92:20:8B:4A:
04:54:6C:21:F1:76:DF:08:A9:0A:A5:D5:D0:17:CA:98:B5:F4:9F:F6:
9C:8F:DA:09:C2:37:FB:36:23:D1:25:27:4C:DB:9B:43:19:EB:55:1C:
DA:32:04:A5:B1:97:F7:A3:3B:82:55:FD:BD:6D:90:BB:61:E6:D3:93:
42:CB:FD:4A:1B:3E:03:43:7D:E3:85:32:91:45:C9:B4:CD:DC:B7:07:
37:58:8A:4A:49:5F:F7:26:41:E1:BB:A1:64:B5:86:00:17:9D:D7:81:
31:BA:DC:BF:04:CC:11:55:B1:C6:24:83:43:33:34:2D:BF:00:74:26:
6A:EC:56:90:C7:1B:C2:78:5C:7F:25:2D:78:BD:C5:D9:7D:69:6A:32:
5D:EF:48:6C:21:64:47:2A:FE:34:3C:58:8D:9E:D7:42:76:BE:89:84:
8D:62:9D:62:DE:7C:88:C4:5F:AA:13:20:6B:90:53:16:4E:06:EE:8A:
DE:F7:EA:F8:92:03:7D:84:B7:0C:9F:A0:52:B7:5E:21:BF:37:6A:C9:
34:6D:69:1E:4A:CC:48:F2:0A:6C:B8:AD:83:C0:8F:76:CC:43:0E:29:
17:A9:22:F3:0B:59:A9:87:24:AD:84:CD:EE:E2:C3:93:F7:A8:11:ED:
9A:CC:DA:7F:9D:73:06:5C:A7:1A:6A:54
Signed-off-by: Mikko Rapeli
---
meta/recipes-kernel/kmod/kmod_30.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/kmod/kmod_30.bb
b/meta/recipes-kernel/kmod/kmod_30.bb
index 8eb83efe6d..ff6e20554b 100644
--- a/meta/recipes-kernel/kmod/kmod_30.bb
+++ b/meta/recipes-kernel/kmod/kmod_30.bb
@@ -26,7 +26,7 @@ S = "${WORKDIR}/git"
EXTRA_OECONF += "--enable-tools"
-PACKAGECONFIG ??= "zlib xz"
+PACKAGECONFIG ??= "zlib xz openssl"
PACKAGECONFIG[debug] = "--enable-debug,--disable-debug"
PACKAGECONFIG[logging] = " --enable-logging,--disable-logging"
PACKAGECONFIG[manpages] = "--enable-manpages, --disable-manpages,
libxslt-native xmlto-native"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173772):
https://lists.openembedded.org/g/openembedded-core/message/173772
Mute This Topic: https://lists.openembedded.org/mt/95255244/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [master][PATCH] tiff: Security fix for CVE-2022-3970
On Nov 25, 2022, at 9:54 AM, Ross Burton wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
master has libtiff 4.4.0 so this doesn’t apply. Is the CVE still valid in that
release, or has it been fixed?
Ross
It seems like this CVE is fixed after 4.4.0 to me.
ZQ
On 22 Nov 2022, at 15:37, Qiu, Zheng via lists.openembedded.org
wrote:
This patch contains a fix for CVE-2022-3970
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2022-3970
https://security-tracker.debian.org/tracker/CVE-2022-3970
Patch generated from :
https://gitlab.com/libtiff/libtiff/-/commit/227500897dfb07fb7d27f7aa570050e62617e3be
Upstream-Status: Accepted
Signed-off-by: Zheng Qiu
---
.../libtiff/tiff/CVE-2022-3970.patch | 38 +++
meta/recipes-multimedia/libtiff/tiff_4.3.0.bb | 1 +
2 files changed, 39 insertions(+)
create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2022-3970.patch
diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2022-3970.patch
b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-3970.patch
new file mode 100644
index 00..e8f143933a
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-3970.patch
@@ -0,0 +1,38 @@
+From 227500897dfb07fb7d27f7aa570050e62617e3be Mon Sep 17 00:00:00 2001
+From: Even Rouault
+Date: Tue, 8 Nov 2022 15:16:58 +0100
+Subject: [PATCH] TIFFReadRGBATileExt(): fix (unsigned) integer overflow on
+ strips/tiles > 2 GB
+
+Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53137
+---
+ libtiff/tif_getimage.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/libtiff/tif_getimage.c b/libtiff/tif_getimage.c
+index a4d0c1d6..60b94d8e 100644
+--- a/libtiff/tif_getimage.c
b/libtiff/tif_getimage.c
+@@ -3016,15 +3016,15 @@ TIFFReadRGBATileExt(TIFF* tif, uint32_t col, uint32_t
row, uint32_t * raster, in
+ return( ok );
+
+ for( i_row = 0; i_row < read_ysize; i_row++ ) {
+-memmove( raster + (tile_ysize - i_row - 1) * tile_xsize,
+- raster + (read_ysize - i_row - 1) * read_xsize,
++memmove( raster + (size_t)(tile_ysize - i_row - 1) * tile_xsize,
++ raster + (size_t)(read_ysize - i_row - 1) * read_xsize,
+ read_xsize * sizeof(uint32_t) );
+-_TIFFmemset( raster + (tile_ysize - i_row - 1) *
tile_xsize+read_xsize,
++_TIFFmemset( raster + (size_t)(tile_ysize - i_row - 1) *
tile_xsize+read_xsize,
+ 0, sizeof(uint32_t) * (tile_xsize - read_xsize) );
+ }
+
+ for( i_row = read_ysize; i_row < tile_ysize; i_row++ ) {
+-_TIFFmemset( raster + (tile_ysize - i_row - 1) * tile_xsize,
++_TIFFmemset( raster + (size_t)(tile_ysize - i_row - 1) * tile_xsize,
+ 0, sizeof(uint32_t) * tile_xsize );
+ }
+
+--
+2.33.0
+
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
index f84057c46b..0fbe515e9d 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
@@ -24,6 +24,7 @@ SRC_URI =
"http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
file://CVE-2022-34526.patch \
file://CVE-2022-2869.patch \
file://CVE-2022-2867.patch \
+ file://CVE-2022-3970.patch \
file://b258ed69a485a9cfb299d9f060eb2a46c54e5903.patch \
"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173771):
https://lists.openembedded.org/g/openembedded-core/message/173771
Mute This Topic: https://lists.openembedded.org/mt/9519/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: Set correct info_dir and status_file in opkg.conf
We’ve had opkg 0.6.0 in master since June, so can you rebase to current master
and resend?
Thanks,
Ross
> On 24 Nov 2022, at 10:52, Harald Seiler via lists.openembedded.org
> wrote:
>
> Distros can customize the location of OPKG data using OPKGLIBDIR. In
> OE-Core commit 11f1956cf5d7 ("package_manager.py: define info_dir and
> status_file when OPKGLIBDIR isn't the default"), a fix was applied to
> correctly set the info_dir and status_file options relative to
> OPKGLIBDIR.
>
> However, as the commit message notes, the opkg.conf file deployed as
> part of the opkg package must also be adjusted to correctly reflect the
> changed location. Otherwise, opkg running inside the image cannot find
> its data.
>
> Fix this by also setting the info_dir and status_file options in
> opkg.conf to the correct location relative to OPKGLIBDIR.
>
> Fixes: 11f1956cf5d7 ("package_manager.py: define info_dir and status_file
> when OPKGLIBDIR isn't the default")
> Signed-off-by: Harald Seiler
> ---
> meta/recipes-devtools/opkg/opkg_0.5.0.bb | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/opkg/opkg_0.5.0.bb
> b/meta/recipes-devtools/opkg/opkg_0.5.0.bb
> index e91d7250bc..7bddaa3016 100644
> --- a/meta/recipes-devtools/opkg/opkg_0.5.0.bb
> +++ b/meta/recipes-devtools/opkg/opkg_0.5.0.bb
> @@ -46,7 +46,9 @@ EXTRA_OECONF:class-native =
> "--localstatedir=/${@os.path.relpath('${localstatedi
> do_install:append () {
> install -d ${D}${sysconfdir}/opkg
> install -m 0644 ${WORKDIR}/opkg.conf ${D}${sysconfdir}/opkg/opkg.conf
> - echo "option lists_dir ${OPKGLIBDIR}/opkg/lists"
> >>${D}${sysconfdir}/opkg/opkg.conf
> + echo "option lists_dir ${OPKGLIBDIR}/opkg/lists"
> >>${D}${sysconfdir}/opkg/opkg.conf
> + echo "option info_dir${OPKGLIBDIR}/opkg/info"
> >>${D}${sysconfdir}/opkg/opkg.conf
> + echo "option status_file ${OPKGLIBDIR}/opkg/status"
> >>${D}${sysconfdir}/opkg/opkg.conf
>
> # We need to create the lock directory
> install -d ${D}${OPKGLIBDIR}/opkg
> --
> 2.38.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173770):
https://lists.openembedded.org/g/openembedded-core/message/173770
Mute This Topic: https://lists.openembedded.org/mt/95235592/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe-core][PATCH] ell: upgrade 0.53 -> 0.54
iwd-2.0 will require ell 0.54
Signed-off-by: Markus Volk
---
meta/recipes-core/ell/{ell_0.53.bb => ell_0.54.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-core/ell/{ell_0.53.bb => ell_0.54.bb} (89%)
diff --git a/meta/recipes-core/ell/ell_0.53.bb
b/meta/recipes-core/ell/ell_0.54.bb
similarity index 89%
rename from meta/recipes-core/ell/ell_0.53.bb
rename to meta/recipes-core/ell/ell_0.54.bb
index 7817476030..5594e0ba54 100644
--- a/meta/recipes-core/ell/ell_0.53.bb
+++ b/meta/recipes-core/ell/ell_0.54.bb
@@ -15,7 +15,7 @@ DEPENDS = "dbus"
inherit autotools pkgconfig
SRC_URI =
"https://mirrors.edge.kernel.org/pub/linux/libs/${BPN}/${BPN}-${PV}.tar.xz";
-SRC_URI[sha256sum] =
"a7d0df846af839bbea1b80f292166371070328854b3fa785b5c607fe600552ad"
+SRC_URI[sha256sum] =
"43be093b25359acd84dd2b07b45a1eacc3a4089bb01342eb3fc99ec9d94a25d9"
do_configure:prepend () {
mkdir -p ${S}/build-aux
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173769):
https://lists.openembedded.org/g/openembedded-core/message/173769
Mute This Topic: https://lists.openembedded.org/mt/95255103/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [master][PATCH] tiff: Security fix for CVE-2022-3970
master has libtiff 4.4.0 so this doesn’t apply. Is the CVE still valid in that
release, or has it been fixed?
Ross
> On 22 Nov 2022, at 15:37, Qiu, Zheng via lists.openembedded.org
> wrote:
>
> This patch contains a fix for CVE-2022-3970
>
> Reference:
> https://nvd.nist.gov/vuln/detail/CVE-2022-3970
> https://security-tracker.debian.org/tracker/CVE-2022-3970
>
> Patch generated from :
> https://gitlab.com/libtiff/libtiff/-/commit/227500897dfb07fb7d27f7aa570050e62617e3be
>
> Upstream-Status: Accepted
>
> Signed-off-by: Zheng Qiu
> ---
> .../libtiff/tiff/CVE-2022-3970.patch | 38 +++
> meta/recipes-multimedia/libtiff/tiff_4.3.0.bb | 1 +
> 2 files changed, 39 insertions(+)
> create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2022-3970.patch
>
> diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2022-3970.patch
> b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-3970.patch
> new file mode 100644
> index 00..e8f143933a
> --- /dev/null
> +++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-3970.patch
> @@ -0,0 +1,38 @@
> +From 227500897dfb07fb7d27f7aa570050e62617e3be Mon Sep 17 00:00:00 2001
> +From: Even Rouault
> +Date: Tue, 8 Nov 2022 15:16:58 +0100
> +Subject: [PATCH] TIFFReadRGBATileExt(): fix (unsigned) integer overflow on
> + strips/tiles > 2 GB
> +
> +Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53137
> +---
> + libtiff/tif_getimage.c | 8
> + 1 file changed, 4 insertions(+), 4 deletions(-)
> +
> +diff --git a/libtiff/tif_getimage.c b/libtiff/tif_getimage.c
> +index a4d0c1d6..60b94d8e 100644
> +--- a/libtiff/tif_getimage.c
> b/libtiff/tif_getimage.c
> +@@ -3016,15 +3016,15 @@ TIFFReadRGBATileExt(TIFF* tif, uint32_t col,
> uint32_t row, uint32_t * raster, in
> + return( ok );
> +
> + for( i_row = 0; i_row < read_ysize; i_row++ ) {
> +-memmove( raster + (tile_ysize - i_row - 1) * tile_xsize,
> +- raster + (read_ysize - i_row - 1) * read_xsize,
> ++memmove( raster + (size_t)(tile_ysize - i_row - 1) * tile_xsize,
> ++ raster + (size_t)(read_ysize - i_row - 1) * read_xsize,
> + read_xsize * sizeof(uint32_t) );
> +-_TIFFmemset( raster + (tile_ysize - i_row - 1) *
> tile_xsize+read_xsize,
> ++_TIFFmemset( raster + (size_t)(tile_ysize - i_row - 1) *
> tile_xsize+read_xsize,
> + 0, sizeof(uint32_t) * (tile_xsize - read_xsize) );
> + }
> +
> + for( i_row = read_ysize; i_row < tile_ysize; i_row++ ) {
> +-_TIFFmemset( raster + (tile_ysize - i_row - 1) * tile_xsize,
> ++_TIFFmemset( raster + (size_t)(tile_ysize - i_row - 1) * tile_xsize,
> + 0, sizeof(uint32_t) * tile_xsize );
> + }
> +
> +--
> +2.33.0
> +
> diff --git a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
> b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
> index f84057c46b..0fbe515e9d 100644
> --- a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
> +++ b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
> @@ -24,6 +24,7 @@ SRC_URI =
> "http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
>file://CVE-2022-34526.patch \
>file://CVE-2022-2869.patch \
>file://CVE-2022-2867.patch \
> + file://CVE-2022-3970.patch \
>file://b258ed69a485a9cfb299d9f060eb2a46c54e5903.patch \
>"
>
> --
> 2.33.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173768):
https://lists.openembedded.org/g/openembedded-core/message/173768
Mute This Topic: https://lists.openembedded.org/mt/9519/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][master][langdale][PATCH] grub2: backport patch to fix CVE-2022-2601 CVE-2022-3775
You don’t actually apply the patches to the recipe in this patch.
Ross
> On 23 Nov 2022, at 06:26, Xiangyu Chen via lists.openembedded.org
> wrote:
>
> Backport patch from upstream to solve CVE-2022-2601 CVE-2022-3775 dependency:
> font: Fix size overflow in grub_font_get_glyph_internal()
> (https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9c76ec09ae08155df27cd237eaea150b4f02f532)
>
> Backport patch from upstream to fix following CVEs:
> CVE-2022-2601: font: Fix several integer overflows in
> grub_font_construct_glyph()
> (https://git.savannah.gnu.org/cgit/grub.git/commit/?id=768e1ef2fc159f6e14e7246e4be09363708ac39e)
> CVE-2022-3775: font: Fix an integer underflow in blit_comb()
> (https://git.savannah.gnu.org/cgit/grub.git/commit/?id=992c06191babc1e109caf40d6a07ec6fdef427af)
>
> Signed-off-by: Xiangyu Chen
> ---
> ...erflow-in-grub_font_get_glyph_intern.patch | 117 ++
> .../grub/files/CVE-2022-2601.patch| 87 +
> .../grub/files/CVE-2022-3775.patch| 97 +++
> 3 files changed, 301 insertions(+)
> create mode 100644
> meta/recipes-bsp/grub/files/0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
> create mode 100644 meta/recipes-bsp/grub/files/CVE-2022-2601.patch
> create mode 100644 meta/recipes-bsp/grub/files/CVE-2022-3775.patch
>
> diff --git
> a/meta/recipes-bsp/grub/files/0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
>
> b/meta/recipes-bsp/grub/files/0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
> new file mode 100644
> index 00..db0fff94d2
> --- /dev/null
> +++
> b/meta/recipes-bsp/grub/files/0001-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch
> @@ -0,0 +1,117 @@
> +From 9c76ec09ae08155df27cd237eaea150b4f02f532 Mon Sep 17 00:00:00 2001
> +From: Zhang Boyang
> +Date: Fri, 5 Aug 2022 00:51:20 +0800
> +Subject: [PATCH] font: Fix size overflow in grub_font_get_glyph_internal()
> +
> +The length of memory allocation and file read may overflow. This patch
> +fixes the problem by using safemath macros.
> +
> +There is a lot of code repetition like "(x * y + 7) / 8". It is unsafe
> +if overflow happens. This patch introduces
> grub_video_bitmap_calc_1bpp_bufsz().
> +It is safe replacement for such code. It has safemath-like prototype.
> +
> +This patch also introduces grub_cast(value, pointer), it casts value to
> +typeof(*pointer) then store the value to *pointer. It returns true when
> +overflow occurs or false if there is no overflow. The semantics of arguments
> +and return value are designed to be consistent with other safemath macros.
> +
> +Signed-off-by: Zhang Boyang
> +Reviewed-by: Daniel Kiper
> +
> +Upstream-Status: Backport from
> +[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9c76ec09ae08155df27cd237eaea150b4f02f532]
> +
> +Signed-off-by: Xiangyu Chen
> +---
> + grub-core/font/font.c | 17 +
> + include/grub/bitmap.h | 18 ++
> + include/grub/safemath.h | 2 ++
> + 3 files changed, 33 insertions(+), 4 deletions(-)
> +
> +diff --git a/grub-core/font/font.c b/grub-core/font/font.c
> +index 756ca0abf..e781521a7 100644
> +--- a/grub-core/font/font.c
> b/grub-core/font/font.c
> +@@ -739,7 +739,8 @@ grub_font_get_glyph_internal (grub_font_t font,
> grub_uint32_t code)
> + grub_int16_t xoff;
> + grub_int16_t yoff;
> + grub_int16_t dwidth;
> +- int len;
> ++ grub_ssize_t len;
> ++ grub_size_t sz;
> +
> + if (index_entry->glyph)
> + /* Return cached glyph. */
> +@@ -768,9 +769,17 @@ grub_font_get_glyph_internal (grub_font_t font,
> grub_uint32_t code)
> + return 0;
> + }
> +
> +- len = (width * height + 7) / 8;
> +- glyph = grub_malloc (sizeof (struct grub_font_glyph) + len);
> +- if (!glyph)
> ++ /* Calculate real struct size of current glyph. */
> ++ if (grub_video_bitmap_calc_1bpp_bufsz (width, height, &len) ||
> ++ grub_add (sizeof (struct grub_font_glyph), len, &sz))
> ++ {
> ++ remove_font (font);
> ++ return 0;
> ++ }
> ++
> ++ /* Allocate and initialize the glyph struct. */
> ++ glyph = grub_malloc (sz);
> ++ if (glyph == NULL)
> + {
> + remove_font (font);
> + return 0;
> +diff --git a/include/grub/bitmap.h b/include/grub/bitmap.h
> +index 149d37bfe..431048936 100644
> +--- a/include/grub/bitmap.h
> b/include/grub/bitmap.h
> +@@ -23,6 +23,7 @@
> + #include
> + #include
> + #include
> ++#include
> +
> + #define IMAGE_HW_MAX_PX 16384
> +
> +@@ -81,6 +82,23 @@ grub_video_bitmap_get_height (struct grub_video_bitmap
> *bitmap)
> + return bitmap->mode_info.height;
> + }
> +
> ++/*
> ++ * Calculate and store the size of data buffer of 1bit bitmap in result.
> ++ * Equivalent to "*result = (width * height + 7) / 8" if no overflow occurs.
> ++ * Return true when overflow occurs or false if there is no overflow.
> ++ * This function is intentionally implemented as a macro instead of
> ++ * an inline fu
Re: [OE-core][PATCH] selftest: allow '-R' and '-r' be used together
Hi Qi, On Fri, 2022-11-25 at 05:56 +, Chen Qi wrote: > The AB is actually running 'all' tests. > > The '--skip-tests (-R)' option means 'Run all (unhidden) tests except > the ones specified.', according to its help message. This is also its > actual effect for now. You can see there's an implicit 'run all > tests' meaning in this option. > The '-T (--exclude-tag)' options means 'Exclude all (unhidden) tests > that match any of the specified tag(s)', according to its help > message. > > So the AB's oe-selftest command means: execute all tests except the > ones tagged with 'machine' and 'toolchain-user', and also skip > 'distrodata.Distrodata.test_checkpkg > buildoptions.SourceMirroring.test_yocto_source_mirror reproducible'. You're right, a different build has -t machine and I'm confusing the two, sorry. I don't really like making changes which require lockstep changes to the autobuilder configuration but I can see why we could do with doing so here. I was thinking there should be symettry between -r and -R like there is with -T and -t but that also probably doesn't make sense when you think about it more. Alex: We'll probably have to work out how to make this change... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173766): https://lists.openembedded.org/g/openembedded-core/message/173766 Mute This Topic: https://lists.openembedded.org/mt/95231396/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 05/17] unfs: update 0.9.22 -> 0.10.0
On Thu, 24 Nov 2022 at 15:08, Alexander Kanavin via lists.openembedded.org wrote: > > Do we need special privileges to be able to run that? > > No, you only need to build meta-ide-support as the scripts take nfsd > executable from sysroot of that (could be improved and available > directly from qemu's own sysroot). > > Then it should simply work if you give the rootfs tarball as parameter > to runqemu: > $ runqemu tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.tar.bz2 > nographic kvm I discovered that there is in fact a selftest for this: https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/runqemu.py#n202 So I went ahead and fixed/cleaned up everything, so that no special hoops are required, and things 'just work' by building an image and then running runqemu, and the selftest is re-enabled and passes. Patches are coming. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173765): https://lists.openembedded.org/g/openembedded-core/message/173765 Mute This Topic: https://lists.openembedded.org/mt/95151297/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][master][kirkstone][PATCH] rng-tools: backport patch to adjust jitterentropy library to timeout/fail on long delay
On 25/11/2022 18:08:12+0800, Xiangyu Chen wrote:
>
> On 11/15/22 16:18, Xiangyu Chen wrote:
> > Backport patch from upstream[1] to adjust jitter to timeout on init after 5
> > seconds in the event it takes
> > to long to gether jitter entropy.This also fix rng-tools take full cpu
> > usage with whole cores on ARM platforms.
> >
> > [1]
> > https://github.com/nhorman/rng-tools/pull/171/commits/c29424f10a0dcbd18ac25607fa1c81c18a960e81
> >
> > Signed-off-by: Xiangyu Chen
>
> Friendly ping, thanks.
I believe this is the cause of this error:
https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/5017/steps/13/logs/stdio
>
>
> > ---
> > ...ropy-library-to-timeout-fail-on-long.patch | 144 ++
> > .../rng-tools/rng-tools_6.15.bb | 1 +
> > 2 files changed, 145 insertions(+)
> > create mode 100644
> > meta/recipes-support/rng-tools/rng-tools/0001-Adjust-jitterentropy-library-to-timeout-fail-on-long.patch
> >
> > diff --git
> > a/meta/recipes-support/rng-tools/rng-tools/0001-Adjust-jitterentropy-library-to-timeout-fail-on-long.patch
> >
> > b/meta/recipes-support/rng-tools/rng-tools/0001-Adjust-jitterentropy-library-to-timeout-fail-on-long.patch
> > new file mode 100644
> > index 00..d70c6587aa
> > --- /dev/null
> > +++
> > b/meta/recipes-support/rng-tools/rng-tools/0001-Adjust-jitterentropy-library-to-timeout-fail-on-long.patch
> > @@ -0,0 +1,144 @@
> > +From 3f1d6e53985e40cbe4c7380ce503ca2778d4cd9d Mon Sep 17 00:00:00 2001
> > +From: Neil Horman
> > +Date: Mon, 16 May 2022 13:38:54 -0400
> > +Subject: [PATCH] Adjust jitterentropy library to timeout/fail on long delay
> > +
> > +When running rngd -l its possible, on platforms that have low jitter
> > +entropy to block for long periods of time. Adjust jitter to timeout on
> > +init after 5 seconds in the event it takes to long to gether jitter
> > +entropy
> > +
> > +Also while we're at it, I might have a build solution for the presence
> > +of internal timers. When jitterentropy is built without internal
> > +timers, jent_notime_init is defined publically, but when it is built
> > +with timers, its declared as a static symbol, preenting resolution, so
> > +we can test to see if the function exists. If it does we _don't_ have
> > +notime support. The logic is a bit backwards, but i think it works
> > +
> > +Upstream-Status: Backport from
> > +[https://github.com/nhorman/rng-tools/pull/171/commits/c29424f10a0dcbd18ac25607fa1c81c18a960e81]
> > +
> > +Signed-off-by: Xiangyu Chen
> > +---
> > + configure.ac | 6 ++---
> > + rngd_jitter.c | 61 +++
> > + 2 files changed, 50 insertions(+), 17 deletions(-)
> > +
> > +diff --git a/configure.ac b/configure.ac
> > +index 40008ca..2e12308 100644
> > +--- a/configure.ac
> > b/configure.ac
> > +@@ -94,9 +94,9 @@ AS_IF(
> > + AC_SEARCH_LIBS(jent_version,jitterentropy,
> > + [AM_CONDITIONAL([JITTER], [true])
> > + AC_DEFINE([HAVE_JITTER],1,[Enable JITTER])
> > +- AC_CHECK_LIB(jitterentropy,
> > jent_entropy_switch_notime_impl,
> > +- [AC_DEFINE([HAVE_JITTER_NOTIME],1,[Enable
> > JITTER_NOTIME])],
> > +- [],-lpthread)],
> > ++ AC_CHECK_LIB(jitterentropy, jent_notime_init,
> > ++ [],
> > ++ [AC_DEFINE([HAVE_JITTER_NOTIME],1, [Enable
> > JITTER_NOTIME])],-lpthread)],
> > + AC_MSG_NOTICE([No Jitterentropy library
> > found]),-lpthread)
> > + ], [AC_MSG_NOTICE([Disabling JITTER entropy source])]
> > + )
> > +diff --git a/rngd_jitter.c b/rngd_jitter.c
> > +index d1b17ba..3647b7f 100644
> > +--- a/rngd_jitter.c
> > b/rngd_jitter.c
> > +@@ -400,6 +400,8 @@ int init_jitter_entropy_source(struct rng *ent_src)
> > + int entflags = 0;
> > + int ret;
> > + int core_id = 0;
> > ++ struct timespec base, now;
> > ++ int rc;
> > +
> > + signal(SIGUSR1, jitter_thread_exit_signal);
> > +
> > +@@ -508,6 +510,10 @@ int init_jitter_entropy_source(struct rng *ent_src)
> > + CPU_FREE(cpus);
> > + cpus = NULL;
> > +
> > ++ flags = fcntl(pipefds[0], F_GETFL, 0);
> > ++ flags |= O_NONBLOCK;
> > ++ fcntl(pipefds[0], F_SETFL, flags);
> > ++
> > + if (ent_src->rng_options[JITTER_OPT_USE_AES].int_val) {
> > + /*
> > +* Temporarily disable aes so we don't try to use it during init
> > +@@ -516,32 +522,59 @@ int init_jitter_entropy_source(struct rng *ent_src)
> > + message_entsrc(ent_src,LOG_CONS|LOG_INFO, "Initializing AES
> > buffer\n");
> > + aes_buf = malloc(tdata[0].buf_sz);
> > + ent_src->rng_options[JITTER_OPT_USE_AES].int_val = 0;
> > +- if (xread_jitter(key, AES_BLOCK, ent_src)) {
> > +- message_entsrc(ent_src,LOG_CONS|LOG_INFO, "Unable to
> > obtain AES key, disabling AES in JIT
Re: [OE-Core][master][kirkstone][PATCH] rng-tools: backport patch to adjust jitterentropy library to timeout/fail on long delay
On 11/15/22 16:18, Xiangyu Chen wrote:
Backport patch from upstream[1] to adjust jitter to timeout on init after 5
seconds in the event it takes
to long to gether jitter entropy.This also fix rng-tools take full cpu usage
with whole cores on ARM platforms.
[1]
https://github.com/nhorman/rng-tools/pull/171/commits/c29424f10a0dcbd18ac25607fa1c81c18a960e81
Signed-off-by: Xiangyu Chen
Friendly ping, thanks.
---
...ropy-library-to-timeout-fail-on-long.patch | 144 ++
.../rng-tools/rng-tools_6.15.bb | 1 +
2 files changed, 145 insertions(+)
create mode 100644
meta/recipes-support/rng-tools/rng-tools/0001-Adjust-jitterentropy-library-to-timeout-fail-on-long.patch
diff --git
a/meta/recipes-support/rng-tools/rng-tools/0001-Adjust-jitterentropy-library-to-timeout-fail-on-long.patch
b/meta/recipes-support/rng-tools/rng-tools/0001-Adjust-jitterentropy-library-to-timeout-fail-on-long.patch
new file mode 100644
index 00..d70c6587aa
--- /dev/null
+++
b/meta/recipes-support/rng-tools/rng-tools/0001-Adjust-jitterentropy-library-to-timeout-fail-on-long.patch
@@ -0,0 +1,144 @@
+From 3f1d6e53985e40cbe4c7380ce503ca2778d4cd9d Mon Sep 17 00:00:00 2001
+From: Neil Horman
+Date: Mon, 16 May 2022 13:38:54 -0400
+Subject: [PATCH] Adjust jitterentropy library to timeout/fail on long delay
+
+When running rngd -l its possible, on platforms that have low jitter
+entropy to block for long periods of time. Adjust jitter to timeout on
+init after 5 seconds in the event it takes to long to gether jitter
+entropy
+
+Also while we're at it, I might have a build solution for the presence
+of internal timers. When jitterentropy is built without internal
+timers, jent_notime_init is defined publically, but when it is built
+with timers, its declared as a static symbol, preenting resolution, so
+we can test to see if the function exists. If it does we _don't_ have
+notime support. The logic is a bit backwards, but i think it works
+
+Upstream-Status: Backport from
+[https://github.com/nhorman/rng-tools/pull/171/commits/c29424f10a0dcbd18ac25607fa1c81c18a960e81]
+
+Signed-off-by: Xiangyu Chen
+---
+ configure.ac | 6 ++---
+ rngd_jitter.c | 61 +++
+ 2 files changed, 50 insertions(+), 17 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 40008ca..2e12308 100644
+--- a/configure.ac
b/configure.ac
+@@ -94,9 +94,9 @@ AS_IF(
+ AC_SEARCH_LIBS(jent_version,jitterentropy,
+ [AM_CONDITIONAL([JITTER], [true])
+ AC_DEFINE([HAVE_JITTER],1,[Enable JITTER])
+- AC_CHECK_LIB(jitterentropy,
jent_entropy_switch_notime_impl,
+- [AC_DEFINE([HAVE_JITTER_NOTIME],1,[Enable
JITTER_NOTIME])],
+- [],-lpthread)],
++ AC_CHECK_LIB(jitterentropy, jent_notime_init,
++ [],
++ [AC_DEFINE([HAVE_JITTER_NOTIME],1, [Enable
JITTER_NOTIME])],-lpthread)],
+ AC_MSG_NOTICE([No Jitterentropy library
found]),-lpthread)
+ ], [AC_MSG_NOTICE([Disabling JITTER entropy source])]
+ )
+diff --git a/rngd_jitter.c b/rngd_jitter.c
+index d1b17ba..3647b7f 100644
+--- a/rngd_jitter.c
b/rngd_jitter.c
+@@ -400,6 +400,8 @@ int init_jitter_entropy_source(struct rng *ent_src)
+ int entflags = 0;
+ int ret;
+ int core_id = 0;
++ struct timespec base, now;
++ int rc;
+
+ signal(SIGUSR1, jitter_thread_exit_signal);
+
+@@ -508,6 +510,10 @@ int init_jitter_entropy_source(struct rng *ent_src)
+ CPU_FREE(cpus);
+ cpus = NULL;
+
++ flags = fcntl(pipefds[0], F_GETFL, 0);
++ flags |= O_NONBLOCK;
++ fcntl(pipefds[0], F_SETFL, flags);
++
+ if (ent_src->rng_options[JITTER_OPT_USE_AES].int_val) {
+ /*
+* Temporarily disable aes so we don't try to use it during init
+@@ -516,32 +522,59 @@ int init_jitter_entropy_source(struct rng *ent_src)
+ message_entsrc(ent_src,LOG_CONS|LOG_INFO, "Initializing AES
buffer\n");
+ aes_buf = malloc(tdata[0].buf_sz);
+ ent_src->rng_options[JITTER_OPT_USE_AES].int_val = 0;
+- if (xread_jitter(key, AES_BLOCK, ent_src)) {
+- message_entsrc(ent_src,LOG_CONS|LOG_INFO, "Unable to obtain
AES key, disabling AES in JITTER source\n");
+- } else if (xread_jitter(iv_buf, CHUNK_SIZE, ent_src)) {
+- message_entsrc(ent_src,LOG_CONS|LOG_INFO, "Unable to obtain
iv_buffer, disabling AES in JITTER source\n");
++ clock_gettime(CLOCK_REALTIME, &base);
++ do {
++ rc = xread_jitter(key, AES_BLOCK, ent_src);
++ clock_gettime(CLOCK_REALTIME, &now);
++ } while (rc && ((now.tv_sec - base.tv_sec) < 5));
++
++
