Date   

[master][PATCH v2 2/2] image_types: Set .7z extension for 7-Zip conversion command

Livius
 

From: Benjamin Szőke <egyszeregy@...>

Signed-off-by: Benjamin Szőke <egyszeregy@...>
---
meta/classes-recipe/image_types.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/image_types.bbclass b/meta/classes-recipe/image_types.bbclass
index f70c71b9d4..ae00728a74 100644
--- a/meta/classes-recipe/image_types.bbclass
+++ b/meta/classes-recipe/image_types.bbclass
@@ -61,7 +61,7 @@ ZIP_COMPRESSION_LEVEL ?= "-9"

7ZIP_COMPRESSION_LEVEL ?= "9"
7ZIP_COMPRESSION_METHOD ?= "BZip2"
-7ZIP_EXTENSION ?= "zip"
+7ZIP_EXTENSION ?= "7z"

ZSTD_COMPRESSION_LEVEL ?= "-3"

--
2.38.1.windows.1


[master][PATCH v2 1/2] image_types: Add 7-Zip support in conversion types and commands

Livius
 

From: Benjamin Szőke <egyszeregy@...>

Add 7-Zip support in conversion types and commands. Default arguments of 7-Zip are compression level: 9, method: BZip2, extension: zip. All these are overridable from local.con for any other use case in user side. First goal was to make an alternative zip conversion which can operate faster in multi-thread systems (on many CPU core), normal zip is just a single thread compression. 7-Zip can do a zip compression in multi-thread processing, so it is fine to use and speed up it.

Signed-off-by: Benjamin Szőke <egyszeregy@...>
---
meta/classes-recipe/image_types.bbclass | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/image_types.bbclass b/meta/classes-recipe/image_types.bbclass
index 764e6a5574..f70c71b9d4 100644
--- a/meta/classes-recipe/image_types.bbclass
+++ b/meta/classes-recipe/image_types.bbclass
@@ -59,6 +59,10 @@ XZ_INTEGRITY_CHECK ?= "crc32"

ZIP_COMPRESSION_LEVEL ?= "-9"

+7ZIP_COMPRESSION_LEVEL ?= "9"
+7ZIP_COMPRESSION_METHOD ?= "BZip2"
+7ZIP_EXTENSION ?= "zip"
+
ZSTD_COMPRESSION_LEVEL ?= "-3"

JFFS2_SUM_EXTRA_ARGS ?= ""
@@ -304,7 +308,7 @@ IMAGE_TYPES:append:x86-64 = " hddimg iso"
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""

-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 gzsync zsync ${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip 7zip zst sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 gzsync zsync ${COMPRESSIONTYPES}"
CONVERSION_CMD:lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:gz = "gzip -f -9 -n -c --rsyncable ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD:bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -312,6 +316,7 @@ CONVERSION_CMD:xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_DEFAULTS} --check=
CONVERSION_CMD:lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:zip = "zip ${ZIP_COMPRESSION_LEVEL} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD:7zip = "7za a -mx=${7ZIP_COMPRESSION_LEVEL} -mm=${7ZIP_COMPRESSION_METHOD} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.${7ZIP_EXTENSION} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:zst = "zstd -f -k -T0 -c ${ZSTD_COMPRESSION_LEVEL} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD:sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD:md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
@@ -337,6 +342,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_7zip = "p7zip-native"
CONVERSION_DEPENDS_zst = "zstd-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
--
2.38.1.windows.1


Re: [master][PATCH v2] image_types: Add 7-Zip support in conversion types and commands

Quentin Schulz
 

Hi Benjamin,

On 11/7/22 12:33, Livius wrote:
Good point for this zip extension conflict, you are right. If somebody is a overzealous developer can use IMAGE_TYPES = "wic.zip wic.7zip" then sure there will be an extension conflict after the compression in deploy time. This escaped my notice this because this use case is not so realistic (normaly enough only one zip pack for wic image) but can be a real issue. 100% sure 7ZIP_EXTENSION ?= 7z can be better for default value, then it can be overridable to .zip extension in users's local.conf if needed (for example for me it .zip will be better).
Do i need to resend again the patch in a new thread/topic if i like to solve the missing signed-off issue?
Yes, please make it a v2 also (git format-patch -v 2 when creating the patch before sending it with git-send-email).

Cheers,
Quentin


Re: [master][PATCH v2] image_types: Add 7-Zip support in conversion types and commands

Livius
 

Good point for this zip extension conflict, you are right. If somebody is a overzealous developer can use IMAGE_TYPES = "wic.zip wic.7zip" then sure there will be an extension conflict after the compression in deploy time. This escaped my notice this because this use case is not so realistic (normaly enough only one zip pack for wic image) but can be a real issue. 100% sure 7ZIP_EXTENSION ?= 7z can be better for default value, then it can be overridable to .zip extension in users's local.conf if needed (for example for me it .zip will be better).

 

Do i need to resend again the patch in a new thread/topic if i like to solve the missing signed-off issue?


Re: [PATCH] systemd: bump to v252

Alexander Kanavin
 

On Mon, 7 Nov 2022 at 11:01, Luca Bocassi <luca.boccassi@...> wrote:
This makes oe-selftest fail:

https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/4353/steps/14/logs/stdio

[ 1.465610] Run /init as init process
[ 1.532366] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input1
[ 1.534612] hid-generic 0003:0627:0001.0001: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:1d.7-1/input0
/init: eval: line 103: syntax error: EOF in backquote substitution
This is a very strange error, I don't think it comes from systemd? Any clue?
This comes from a specific selftest:

wic.Wic2.test_efi_plugin_unified_kernel_image_qemu

You should replicate what the test does, so you can see the issue
first hand - or confirm that it's not the new systemd:
https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/wic.py#n1171

Particularly the wic plugin used by the test does refer to systemd:
https://git.yoctoproject.org/poky/tree/meta-selftest/wic/test_efi_plugin.wks

Alex


Re: [PATCH] systemd: bump to v252

Luca Bocassi
 

On Sun, 6 Nov 2022 at 15:36, Alexandre Belloni
<alexandre.belloni@...> wrote:

Hello,

This makes oe-selftest fail:

https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/4353/steps/14/logs/stdio

[ 1.465610] Run /init as init process
[ 1.532366] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input1
[ 1.534612] hid-generic 0003:0627:0001.0001: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:1d.7-1/input0
/init: eval: line 103: syntax error: EOF in backquote substitution
This is a very strange error, I don't think it comes from systemd? Any clue?

Kind regards,
Luca Boccassi


Re: [PATCH] mirrors.bbclass: use shallow tarball for nativesdk-binutils

Etienne Cordonnier
 

I've resent the patch and changed git's sendemail.envelopesender option so that the From field matches the email used in the SOB field.


On Sun, Nov 6, 2022 at 5:02 PM Alexandre Belloni <alexandre.belloni@...> wrote:
On 04/11/2022 15:24:43+0100, Etienne Cordonnier via lists.openembedded.org wrote:
> This is useful e.g. when using meta-clang, which introduces a dependency to nativesdk-binutils when
> populating the SDK, and then a full tarball of binutils is fetched additionally to a shallow tarball.
>
> Signed-off-by: Etienne Cordonnier <ecordonnier@...>

The SoB needs to match the author and sender. You are using two
different addresses here.

> ---
>  meta/classes-global/mirrors.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes-global/mirrors.bbclass b/meta/classes-global/mirrors.bbclass
> index 81fef7f660..8b984de3bf 100644
> --- a/meta/classes-global/mirrors.bbclass
> +++ b/meta/classes-global/mirrors.bbclass
> @@ -91,6 +91,8 @@ BB_GIT_SHALLOW:pn-binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} = "1"
>  BB_GIT_SHALLOW:pn-binutils-cross-testsuite = "1"
>  BB_GIT_SHALLOW:pn-binutils-crosssdk-${SDK_SYS} = "1"
>  BB_GIT_SHALLOW:pn-binutils-native = "1"
> +BB_GIT_SHALLOW:pn-nativesdk-binutils = "1"
> +
>  BB_GIT_SHALLOW:pn-glibc = "1"
>  PREMIRRORS += "git://sourceware.org/git/glibc.git https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.yoctoproject.org_mirror_sources_&d=DwIBAg&c=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw&r=AhkbNonVuMIGRfPx_Qj9TsRih1DULJTKUkSGa66m67E&m=ItIZIiBFvPUc7ha-blv_xFb0FMnb2T_GL7CNoIiQdZKZOHxwxi75uwo6Hol3J3TA&s=hk4_w8STTvGIN0VNAn2uzyYG_oOrycryBPA5-pYHAPg&e=  \
>                git://sourceware.org/git/binutils-gdb.git https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.yoctoproject.org_mirror_sources_&d=DwIBAg&c=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw&r=AhkbNonVuMIGRfPx_Qj9TsRih1DULJTKUkSGa66m67E&m=ItIZIiBFvPUc7ha-blv_xFb0FMnb2T_GL7CNoIiQdZKZOHxwxi75uwo6Hol3J3TA&s=hk4_w8STTvGIN0VNAn2uzyYG_oOrycryBPA5-pYHAPg&e= "
> --
> 2.36.1.vfs.0.0
>

>
>
>


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://urldefense.proofpoint.com/v2/url?u=https-3A__bootlin.com&d=DwIBAg&c=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw&r=AhkbNonVuMIGRfPx_Qj9TsRih1DULJTKUkSGa66m67E&m=ItIZIiBFvPUc7ha-blv_xFb0FMnb2T_GL7CNoIiQdZKZOHxwxi75uwo6Hol3J3TA&s=Lu5F2iWAYyxz6ynKWLlP56TD2uUQTBZBQSCOpzaMaRI&e=


Re: Private: Re: [OE-core] [PATCH 0/1] add python3-brotli_1.0.9 in meta/recipes-devtools/python

Ross Burton
 

Re-adding oe-core to the CC as this discussion should be on the list.

I suggest you add the recipe to meta-python then.

Ross

On 5 Nov 2022, at 07:58, cp0613 <cp0613@...> wrote:

Thanks. This is my first submission and there may be some operation is wrong. I will continue to try git-send-email.

The reason for using python3-brotli is that this library is dependent on many other projects. However, it cannot be installed directly through pip3 on the RISCV platform. Therefore, we use yocto to compile it. We find that many python bb are here, so we add them here.


Re: [master][PATCH v2] image_types: Add 7-Zip support in conversion types and commands

Alexander Kanavin
 

On Mon, 7 Nov 2022 at 10:46, Quentin Schulz via lists.openembedded.org
<quentin.schulz=theobroma-systems.com@...> wrote:
+CONVERSION_DEPENDS_7zip = "p7zip-native"
This tool is in meta-openembedded/meta-oe and not openembedded-core,
should we actually move the recipe into oe-core?
I don't think so. There's plenty of references in oe-core recipes to
recipes that are not in core, as long as they're not used by default.

Alex


[PATCH] mirrors.bbclass: use shallow tarball for nativesdk-binutils

Etienne Cordonnier
 

This is useful e.g. when using meta-clang, which introduces a dependency to nativesdk-binutils when
populating the SDK, and then a full tarball of binutils is fetched additionally to a shallow tarball.

Signed-off-by: Etienne Cordonnier <ecordonnier@...>
---
meta/classes-global/mirrors.bbclass | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta/classes-global/mirrors.bbclass b/meta/classes-global/mirrors.bbclass
index 81fef7f660..8b984de3bf 100644
--- a/meta/classes-global/mirrors.bbclass
+++ b/meta/classes-global/mirrors.bbclass
@@ -91,6 +91,8 @@ BB_GIT_SHALLOW:pn-binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} = "1"
BB_GIT_SHALLOW:pn-binutils-cross-testsuite = "1"
BB_GIT_SHALLOW:pn-binutils-crosssdk-${SDK_SYS} = "1"
BB_GIT_SHALLOW:pn-binutils-native = "1"
+BB_GIT_SHALLOW:pn-nativesdk-binutils = "1"
+
BB_GIT_SHALLOW:pn-glibc = "1"
PREMIRRORS += "git://sourceware.org/git/glibc.git https://downloads.yoctoproject.org/mirror/sources/ \
git://sourceware.org/git/binutils-gdb.git https://downloads.yoctoproject.org/mirror/sources/"
--
2.36.1.vfs.0.0


Re: [master][PATCH v2] image_types: Add 7-Zip support in conversion types and commands

Quentin Schulz
 

Hi Benjamin,

On 11/6/22 14:31, Livius wrote:
From: Benjamin Szőke <egyszeregy@...>
Add 7-Zip support in conversion types and commands. Default arguments of 7-Zip are compression level: 9, method: BZip2, extension: zip. All these are overridable from local.con for any other use case in user side. First goal was to make an alternative zip conversion which can operate faster in multi-thread systems (on many CPU core), normal zip is just a single thread compression. 7-Zip can do a zip compression in multi-thread processing, so it is fine to use and speed up it.
Your signed-off-by is missing here, it is usually added when you run
git commit --signoff
git commit -s

You can add your signature to your patch locally with
git commit --signoff --amend --no-edit

---
meta/classes-recipe/image_types.bbclass | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/classes-recipe/image_types.bbclass b/meta/classes-recipe/image_types.bbclass
index 764e6a5574..f70c71b9d4 100644
--- a/meta/classes-recipe/image_types.bbclass
+++ b/meta/classes-recipe/image_types.bbclass
@@ -59,6 +59,10 @@ XZ_INTEGRITY_CHECK ?= "crc32"
ZIP_COMPRESSION_LEVEL ?= "-9"
+7ZIP_COMPRESSION_LEVEL ?= "9"
+7ZIP_COMPRESSION_METHOD ?= "BZip2"
+7ZIP_EXTENSION ?= "zip"
Wouldn't this conflict with the output of the zip compression? Basically, if I have 7zip and zip for an archive, they will overwrite each other un-deterministically. Maybe the default .7z extension is better?

+
ZSTD_COMPRESSION_LEVEL ?= "-3"
JFFS2_SUM_EXTRA_ARGS ?= ""
@@ -304,7 +308,7 @@ IMAGE_TYPES:append:x86-64 = " hddimg iso"
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 gzsync zsync ${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip 7zip zst sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 gzsync zsync ${COMPRESSIONTYPES}"
CONVERSION_CMD:lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:gz = "gzip -f -9 -n -c --rsyncable ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD:bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -312,6 +316,7 @@ CONVERSION_CMD:xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_DEFAULTS} --check=
CONVERSION_CMD:lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:zip = "zip ${ZIP_COMPRESSION_LEVEL} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD:7zip = "7za a -mx=${7ZIP_COMPRESSION_LEVEL} -mm=${7ZIP_COMPRESSION_METHOD} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.${7ZIP_EXTENSION} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:zst = "zstd -f -k -T0 -c ${ZSTD_COMPRESSION_LEVEL} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD:sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD:md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
@@ -337,6 +342,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_7zip = "p7zip-native"
This tool is in meta-openembedded/meta-oe and not openembedded-core, should we actually move the recipe into oe-core?

Cheers,
Quentin


Re: [kirkstone 06/31] tiff: fix CVE-2022-2953

Shubham Kulkarni
 

Hello, I am new to this community and trying to understand the CVE patch fixing process. Kindly correct me if I am wrong with my understanding.

So, this patch is fixing the code present in the file tools/tiffcrop.c . I can see this patch is having combined changes from following commits:

1] https://gitlab.com/libtiff/libtiff/-/commit/e319508 - tiffcrop: Fix issue #330 and some more from 320 to 349
2] https://gitlab.com/libtiff/libtiff/-/commit/8fe3735  - According to Richard Nolde #401 (comment 877637400) 
3] https://gitlab.com/libtiff/libtiff/-/commit/bad48e9 - tiffcrop -S option: Make decision simpler.

Debian website for this CVE (https://security-tracker.debian.org/tracker/CVE-2022-2953) suggests commits "2]" & "3]" as a fix. And both "2]" & "3]" fixes the code introduced by commit "1]". So, can we say that the vulnerability was introduced by commit "1]" , and solved by "2]" & "3]" ?

If yes, then as per my understanding, there is no need of fixing, as vulnerability itself is not present in current code and it's Not Affected by the CVE. But this patch is introducing the vulnerability ("1]") and on top of it, fixing the same ("2]" & "3]"). Is it required Or can we just say that this version of code/tiff package is not affected by this CVE?
Please rectify my understanding.

Thanks in Advance,
Shubham


On Fri, Nov 4, 2022 at 8:31 AM Steve Sakoman <steve@...> wrote:
From: Zheng Qiu <zheng.qiu@...>

While this does not happen with the tiff 4.3.0 release, it does happen with
the series of patches we have, so backport the two simple changes that
restrict the tiffcrop options to avoid the vulnerability.

CVE-2022-2953.patch was taken from upstream, and a small typo was fixed
for the CVE number. The other patch is included in tiff 4.4.0 but not
4.3.0, so add it as well.

Signed-off-by: Randy MacLeod <randy.macleod@...>
Signed-off-by: Zheng Qiu <zheng.qiu@...>
Signed-off-by: Steve Sakoman <steve@...>
---
 ...ue-330-and-some-more-from-320-to-349.patch | 609 ++++++++++++++++++
 .../libtiff/tiff/CVE-2022-2953.patch          |  87 +++
 meta/recipes-multimedia/libtiff/tiff_4.3.0.bb |   2 +
 3 files changed, 698 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/0001-tiffcrop-Fix-issue-330-and-some-more-from-320-to-349.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2022-2953.patch

diff --git a/meta/recipes-multimedia/libtiff/tiff/0001-tiffcrop-Fix-issue-330-and-some-more-from-320-to-349.patch b/meta/recipes-multimedia/libtiff/tiff/0001-tiffcrop-Fix-issue-330-and-some-more-from-320-to-349.patch
new file mode 100644
index 0000000000..07acf5eb90
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/0001-tiffcrop-Fix-issue-330-and-some-more-from-320-to-349.patch
@@ -0,0 +1,609 @@
+From e319508023580e2f70e6e626f745b5b2a1707313 Mon Sep 17 00:00:00 2001
+From: Su Laus <sulau@...>
+Date: Tue, 10 May 2022 20:03:17 +0000
+Subject: [PATCH] tiffcrop: Fix issue #330 and some more from 320 to 349
+Upstream-Status: Backport
+Signed-off-by: Zheng Qiu <zheng.qiu@...>
+---
+ tools/tiffcrop.c | 282 +++++++++++++++++++++++++++++++++++------------
+ 1 file changed, 210 insertions(+), 72 deletions(-)
+
+diff --git a/tools/tiffcrop.c b/tools/tiffcrop.c
+index 77cf6ed1..791ec5e7 100644
+--- a/tools/tiffcrop.c
++++ b/tools/tiffcrop.c
+@@ -63,20 +63,24 @@
+  *                units when sectioning image into columns x rows
+  *                using the -S cols:rows option.
+  * -X #           Horizontal dimension of region to extract expressed in current
+- *                units
++ *                units, relative to the specified origin reference 'edge' left (default for X) or right.
+  * -Y #           Vertical dimension of region to extract expressed in current
+- *                units
++ *                units, relative to the specified origin reference 'edge' top (default for Y) or bottom.
+  * -O orient      Orientation for output image, portrait, landscape, auto
+  * -P page        Page size for output image segments, eg letter, legal, tabloid,
+  *                etc.
+  * -S cols:rows   Divide the image into equal sized segments using cols across
+  *                and rows down
+- * -E t|l|r|b     Edge to use as origin
++ * -E t|l|r|b     Edge to use as origin (i.e. 'side' of the image not 'corner')
++ *                  top    = width from left, zones from top to bottom (default)
++ *                  bottom = width from left, zones from bottom to top
++ *                  left   = zones from left to right, length from top
++ *                  right  = zones from right to left, length from top
+  * -m #,#,#,#     Margins from edges for selection: top, left, bottom, right
+  *                (commas separated)
+  * -Z #:#,#:#     Zones of the image designated as zone X of Y,
+  *                eg 1:3 would be first of three equal portions measured
+- *                from reference edge
++ *                from reference edge (i.e. 'side' not corner)
+  * -N odd|even|#,#-#,#|last
+  *                Select sequences and/or ranges of images within file
+  *                to process. The words odd or even may be used to specify
+@@ -103,10 +107,13 @@
+  *                selects which functions dump data, with higher numbers selecting
+  *                lower level, scanline level routines. Debug reports a limited set
+  *                of messages to monitor progress without enabling dump logs.
++ *
++ * Note:    The (-X|-Y), -Z and -z options are mutually exclusive.
++ *          In no case should the options be applied to a given selection successively.
+  */
+
+-static   char tiffcrop_version_id[] = "2.4.1";
+-static   char tiffcrop_rev_date[] = "03-03-2010";
++static   char tiffcrop_version_id[] = "2.5";
++static   char tiffcrop_rev_date[] = "02-09-2022";
+
+ #include "tif_config.h"
+ #include "libport.h"
+@@ -774,6 +781,9 @@ static const char usage_info[] =
+ "             The four debug/dump options are independent, though it makes little sense to\n"
+ "             specify a dump file without specifying a detail level.\n"
+ "\n"
++"Note:        The (-X|-Y), -Z and -z options are mutually exclusive.\n"
++"             In no case should the options be applied to a given selection successively.\n"
++"\n"
+ ;
+
+ /* This function could be modified to pass starting sample offset
+@@ -2121,6 +2131,15 @@ void  process_command_opts (int argc, char *argv[], char *mp, char *mode, uint32
+               /*NOTREACHED*/
+       }
+     }
++    /*-- Check for not allowed combinations (e.g. -X, -Y and -Z and -z are mutually exclusive) --*/
++    char XY, Z, R;
++    XY = ((crop_data->crop_mode & CROP_WIDTH) || (crop_data->crop_mode & CROP_LENGTH));
++    Z = (crop_data->crop_mode & CROP_ZONES);
++    R = (crop_data->crop_mode & CROP_REGIONS);
++    if ((XY && Z) || (XY && R) || (Z && R)) {
++        TIFFError("tiffcrop input error", "The crop options(-X|-Y), -Z and -z are mutually exclusive.->Exit");
++        exit(EXIT_FAILURE);
++    }
+   }  /* end process_command_opts */
+
+ /* Start a new output file if one has not been previously opened or
+@@ -2746,7 +2765,7 @@ extractContigSamplesBytes (uint8_t *in, uint8_t *out, uint32_t cols,
+                            tsample_t count, uint32_t start, uint32_t end)
+   {
+   int i, bytes_per_sample, sindex;
+-  uint32_t col, dst_rowsize, bit_offset;
++  uint32_t col, dst_rowsize, bit_offset, numcols;
+   uint32_t src_byte /*, src_bit */;
+   uint8_t *src = in;
+   uint8_t *dst = out;
+@@ -2757,6 +2776,10 @@ extractContigSamplesBytes (uint8_t *in, uint8_t *out, uint32_t cols,
+     return (1);
+     }
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamplesBytes",
+@@ -2769,6 +2792,9 @@ extractContigSamplesBytes (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
+
+   dst_rowsize = (bps * (end - start) * count) / 8;
+
+@@ -2812,7 +2838,7 @@ extractContigSamples8bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                            tsample_t count, uint32_t start, uint32_t end)
+   {
+   int    ready_bits = 0, sindex = 0;
+-  uint32_t col, src_byte, src_bit, bit_offset;
++  uint32_t col, src_byte, src_bit, bit_offset, numcols;
+   uint8_t  maskbits = 0, matchbits = 0;
+   uint8_t  buff1 = 0, buff2 = 0;
+   uint8_t *src = in;
+@@ -2824,6 +2850,10 @@ extractContigSamples8bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     return (1);
+     }
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamples8bits",
+@@ -2836,7 +2866,10 @@ extractContigSamples8bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
+- 
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
++
+   ready_bits = 0;
+   maskbits =  (uint8_t)-1 >> (8 - bps);
+   buff1 = buff2 = 0;
+@@ -2889,7 +2922,7 @@ extractContigSamples16bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                             tsample_t count, uint32_t start, uint32_t end)
+   {
+   int    ready_bits = 0, sindex = 0;
+-  uint32_t col, src_byte, src_bit, bit_offset;
++  uint32_t col, src_byte, src_bit, bit_offset, numcols;
+   uint16_t maskbits = 0, matchbits = 0;
+   uint16_t buff1 = 0, buff2 = 0;
+   uint8_t  bytebuff = 0;
+@@ -2902,6 +2935,10 @@ extractContigSamples16bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     return (1);
+     }
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamples16bits",
+@@ -2914,6 +2951,9 @@ extractContigSamples16bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
+
+   ready_bits = 0;
+   maskbits = (uint16_t)-1 >> (16 - bps);
+@@ -2978,7 +3018,7 @@ extractContigSamples24bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                             tsample_t count, uint32_t start, uint32_t end)
+   {
+   int    ready_bits = 0, sindex = 0;
+-  uint32_t col, src_byte, src_bit, bit_offset;
++  uint32_t col, src_byte, src_bit, bit_offset, numcols;
+   uint32_t maskbits = 0, matchbits = 0;
+   uint32_t buff1 = 0, buff2 = 0;
+   uint8_t  bytebuff1 = 0, bytebuff2 = 0;
+@@ -2991,6 +3031,10 @@ extractContigSamples24bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     return (1);
+     }
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamples24bits",
+@@ -3003,6 +3047,9 @@ extractContigSamples24bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
+
+   ready_bits = 0;
+   maskbits =  (uint32_t)-1 >> (32 - bps);
+@@ -3087,7 +3134,7 @@ extractContigSamples32bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                             tsample_t count, uint32_t start, uint32_t end)
+   {
+   int    ready_bits = 0, sindex = 0 /*, shift_width = 0 */;
+-  uint32_t col, src_byte, src_bit, bit_offset;
++  uint32_t col, src_byte, src_bit, bit_offset, numcols;
+   uint32_t longbuff1 = 0, longbuff2 = 0;
+   uint64_t maskbits = 0, matchbits = 0;
+   uint64_t buff1 = 0, buff2 = 0, buff3 = 0;
+@@ -3102,6 +3149,10 @@ extractContigSamples32bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     }
+
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamples32bits",
+@@ -3114,6 +3165,9 @@ extractContigSamples32bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
+
+   /* shift_width = ((bps + 7) / 8) + 1; */
+   ready_bits = 0;
+@@ -3193,7 +3247,7 @@ extractContigSamplesShifted8bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                                   int shift)
+   {
+   int    ready_bits = 0, sindex = 0;
+-  uint32_t col, src_byte, src_bit, bit_offset;
++  uint32_t col, src_byte, src_bit, bit_offset, numcols;
+   uint8_t  maskbits = 0, matchbits = 0;
+   uint8_t  buff1 = 0, buff2 = 0;
+   uint8_t *src = in;
+@@ -3205,6 +3259,10 @@ extractContigSamplesShifted8bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     return (1);
+     }
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamplesShifted8bits",
+@@ -3217,6 +3275,9 @@ extractContigSamplesShifted8bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
+
+   ready_bits = shift;
+   maskbits =  (uint8_t)-1 >> (8 - bps);
+@@ -3273,7 +3334,7 @@ extractContigSamplesShifted16bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                                    int shift)
+   {
+   int    ready_bits = 0, sindex = 0;
+-  uint32_t col, src_byte, src_bit, bit_offset;
++  uint32_t col, src_byte, src_bit, bit_offset, numcols;
+   uint16_t maskbits = 0, matchbits = 0;
+   uint16_t buff1 = 0, buff2 = 0;
+   uint8_t  bytebuff = 0;
+@@ -3286,6 +3347,10 @@ extractContigSamplesShifted16bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     return (1);
+     }
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamplesShifted16bits",
+@@ -3298,6 +3363,9 @@ extractContigSamplesShifted16bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
+
+   ready_bits = shift;
+   maskbits = (uint16_t)-1 >> (16 - bps);
+@@ -3363,7 +3431,7 @@ extractContigSamplesShifted24bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                                    int shift)
+   {
+   int    ready_bits = 0, sindex = 0;
+-  uint32_t col, src_byte, src_bit, bit_offset;
++  uint32_t col, src_byte, src_bit, bit_offset, numcols;
+   uint32_t maskbits = 0, matchbits = 0;
+   uint32_t buff1 = 0, buff2 = 0;
+   uint8_t  bytebuff1 = 0, bytebuff2 = 0;
+@@ -3376,6 +3444,16 @@ extractContigSamplesShifted24bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     return (1);
+     }
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  /*--- Remark, which is true for all those functions extractCongigSamplesXXX() --
++  *  The mitigation of the start/end test does not allways make sense, because the function is often called with e.g.:
++  *  start = 31; end = 32; cols = 32  to extract the last column in a 32x32 sample image.
++  *  If then, a worng parameter (e.g. cols = 10) is provided, the mitigated settings would be start=0; end=1.
++  *  Therefore, an error message and no copy action might be the better reaction to wrong parameter configurations.
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamplesShifted24bits",
+@@ -3388,6 +3466,9 @@ extractContigSamplesShifted24bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
+
+   ready_bits = shift;
+   maskbits =  (uint32_t)-1 >> (32 - bps);
+@@ -3449,7 +3530,7 @@ extractContigSamplesShifted24bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     buff2 = (buff2 << 8);
+     bytebuff2 = bytebuff1;
+     ready_bits -= 8;
+-    }
++  }
+   
+   return (0);
+   } /* end extractContigSamplesShifted24bits */
+@@ -3461,7 +3542,7 @@ extractContigSamplesShifted32bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                                    int shift)
+   {
+   int    ready_bits = 0, sindex = 0 /*, shift_width = 0 */;
+-  uint32_t col, src_byte, src_bit, bit_offset;
++  uint32_t col, src_byte, src_bit, bit_offset, numcols;
+   uint32_t longbuff1 = 0, longbuff2 = 0;
+   uint64_t maskbits = 0, matchbits = 0;
+   uint64_t buff1 = 0, buff2 = 0, buff3 = 0;
+@@ -3476,6 +3557,10 @@ extractContigSamplesShifted32bits (uint8_t *in, uint8_t *out, uint32_t cols,
+     }
+
+
++  /* Number of extracted columns shall be kept as (end-start + 1). Otherwise buffer-overflow might occur.
++   * 'start' and 'col' count from 0 to (cols-1)  but 'end' is to be set one after the index of the last column to be copied!
++   */
++  numcols = abs(end - start);
+   if ((start > end) || (start > cols))
+     {
+     TIFFError ("extractContigSamplesShifted32bits",
+@@ -3488,6 +3573,9 @@ extractContigSamplesShifted32bits (uint8_t *in, uint8_t *out, uint32_t cols,
+                "Invalid end column value %"PRIu32" ignored", end);
+     end = cols;
+     }
++  if (abs(end - start) > numcols) {
++      end = start + numcols;
++  }
+
+   /* shift_width = ((bps + 7) / 8) + 1; */
+   ready_bits = shift;
+@@ -5429,7 +5517,7 @@ getCropOffsets(struct image_data *image, struct crop_mask *crop, struct dump_opt
+   {
+   struct offset offsets;
+   int    i;
+-  int32_t  test;
++  uint32_t uaux;
+   uint32_t seg, total, need_buff = 0;
+   uint32_t buffsize;
+   uint32_t zwidth, zlength;
+@@ -5510,8 +5598,13 @@ getCropOffsets(struct image_data *image, struct crop_mask *crop, struct dump_opt
+     seg = crop->zonelist[j].position;
+     total = crop->zonelist[j].total;
+
+-    /* check for not allowed zone cases like 0:0; 4:3; etc. and skip that input */
++    /* check for not allowed zone cases like 0:0; 4:3; or negative ones etc. and skip that input */
++    if (crop->zonelist[j].position < 0 || crop->zonelist[j].total < 0) {
++        TIFFError("getCropOffsets", "Negative crop zone values %d:%d are not allowed, thus skipped.", crop->zonelist[j].position, crop->zonelist[j].total);
++        continue;
++    }
+     if (seg == 0 || total == 0 || seg > total) {
++        TIFFError("getCropOffsets", "Crop zone %d:%d is out of specification, thus skipped.", seg, total);
+         continue;
+     }
+
+@@ -5524,17 +5617,23 @@ getCropOffsets(struct image_data *image, struct crop_mask *crop, struct dump_opt
+
+            crop->regionlist[i].x1 = offsets.startx +
+                                   (uint32_t)(offsets.crop_width * 1.0 * (seg - 1) / total);
+-           test = (int32_t)offsets.startx +
+-                  (int32_t)(offsets.crop_width * 1.0 * seg / total);
+-           if (test < 1 )
+-             crop->regionlist[i].x2 = 0;
+-           else
+-           {
+-           if (test > (int32_t)(image->width - 1))
++           /* FAULT: IMHO in the old code here, the calculation of x2 was based on wrong assumtions. The whole image was assumed and 'endy' and 'starty' are not respected anymore!*/
++           /* NEW PROPOSED Code: Assumption: offsets are within image with top left corner as origin (0,0) and 'start' <= 'end'. */
++           if (crop->regionlist[i].x1 > offsets.endx) {
++                crop->regionlist[i].x1 = offsets.endx;
++           } else if (crop->regionlist[i].x1 >= image->width) {
++               crop->regionlist[i].x1 = image->width - 1;
++           }
++
++           crop->regionlist[i].x2 = offsets.startx + (uint32_t)(offsets.crop_width * 1.0 * seg / total);
++           if (crop->regionlist[i].x2 > 0) crop->regionlist[i].x2 = crop->regionlist[i].x2 - 1;
++           if (crop->regionlist[i].x2 < crop->regionlist[i].x1) {
++               crop->regionlist[i].x2 = crop->regionlist[i].x1;
++           } else if (crop->regionlist[i].x2 > offsets.endx) {
++               crop->regionlist[i].x2 = offsets.endx;
++           } else if (crop->regionlist[i].x2 >= image->width) {
+                crop->regionlist[i].x2 = image->width - 1;
+-             else
+-             crop->regionlist[i].x2 = test - 1;
+-             }
++           }
+            zwidth = crop->regionlist[i].x2 - crop->regionlist[i].x1  + 1;
+
+          /* This is passed to extractCropZone or extractCompositeZones */
+@@ -5549,22 +5648,27 @@ getCropOffsets(struct image_data *image, struct crop_mask *crop, struct dump_opt
+          crop->regionlist[i].x1 = offsets.startx;
+            crop->regionlist[i].x2 = offsets.endx;
+
+-           test = offsets.endy - (uint32_t)(offsets.crop_length * 1.0 * seg / total);
+-           if (test < 1 )
+-           crop->regionlist[i].y1 = 0;
+-           else
+-           crop->regionlist[i].y1 = test + 1;
++           /* FAULT: IMHO in the old code here, the calculation of y1/y2 was based on wrong assumtions. The whole image was assumed and 'endy' and 'starty' are not respected anymore!*/
++           /* NEW PROPOSED Code: Assumption: offsets are within image with top left corner as origin (0,0) and 'start' <= 'end'. */
++           uaux = (uint32_t)(offsets.crop_length * 1.0 * seg / total);
++           if (uaux <= offsets.endy + 1) {
++               crop->regionlist[i].y1 = offsets.endy - uaux + 1;
++           } else {
++               crop->regionlist[i].y1 = 0;
++           }
++           if (crop->regionlist[i].y1 < offsets.starty) {
++               crop->regionlist[i].y1 = offsets.starty;
++           }
+
+-           test = offsets.endy - (offsets.crop_length * 1.0 * (seg - 1) / total);
+-           if (test < 1 )
+-             crop->regionlist[i].y2 = 0;
+-           else
+-           {
+-             if (test > (int32_t)(image->length - 1))
+-               crop->regionlist[i].y2 = image->length - 1;
+-             else
+-               crop->regionlist[i].y2 = test;
+-           }
++           uaux = (uint32_t)(offsets.crop_length * 1.0 * (seg - 1) / total);
++           if (uaux <= offsets.endy) {
++               crop->regionlist[i].y2 = offsets.endy - uaux;
++           } else {
++               crop->regionlist[i].y2 = 0;
++           }
++           if (crop->regionlist[i].y2 < offsets.starty) {
++               crop->regionlist[i].y2 = offsets.starty;
++           }
+            zlength = crop->regionlist[i].y2 - crop->regionlist[i].y1 + 1;
+
+          /* This is passed to extractCropZone or extractCompositeZones */
+@@ -5575,32 +5679,42 @@ getCropOffsets(struct image_data *image, struct crop_mask *crop, struct dump_opt
+            crop->combined_width = (uint32_t)zwidth;
+            break;
+       case EDGE_RIGHT: /* zones from right to left, length from top */
+-           zlength = offsets.crop_length;
+-         crop->regionlist[i].y1 = offsets.starty;
+-           crop->regionlist[i].y2 = offsets.endy;
+-
+-           crop->regionlist[i].x1 = offsets.startx +
+-                                  (uint32_t)(offsets.crop_width * (total - seg) * 1.0 / total);
+-           test = offsets.startx +
+-                (offsets.crop_width * (total - seg + 1) * 1.0 / total);
+-           if (test < 1 )
+-             crop->regionlist[i].x2 = 0;
+-           else
+-           {
+-           if (test > (int32_t)(image->width - 1))
+-               crop->regionlist[i].x2 = image->width - 1;
+-             else
+-               crop->regionlist[i].x2 = test - 1;
+-             }
+-           zwidth = crop->regionlist[i].x2 - crop->regionlist[i].x1  + 1;
++                zlength = offsets.crop_length;
++                crop->regionlist[i].y1 = offsets.starty;
++                crop->regionlist[i].y2 = offsets.endy;
++
++                crop->regionlist[i].x1 = offsets.startx +
++                        (uint32_t)(offsets.crop_width * (total - seg) * 1.0 / total);
++          /* FAULT: IMHO from here on, the calculation of y2 are based on wrong assumtions. The whole image is assumed and 'endy' and 'starty' are not respected anymore!*/
++          /* NEW PROPOSED Code: Assumption: offsets are within image with top left corner as origin (0,0) and 'start' <= 'end'. */
++          uaux = (uint32_t)(offsets.crop_width * 1.0 * seg / total);
++          if (uaux <= offsets.endx + 1) {
++              crop->regionlist[i].x1 = offsets.endx - uaux + 1;
++          } else {
++              crop->regionlist[i].x1 = 0;
++          }
++          if (crop->regionlist[i].x1 < offsets.startx) {
++              crop->regionlist[i].x1 = offsets.startx;
++          }
+
+-         /* This is passed to extractCropZone or extractCompositeZones */
+-           crop->combined_length = (uint32_t)zlength;
+-           if (crop->exp_mode == COMPOSITE_IMAGES)
+-             crop->combined_width += (uint32_t)zwidth;
+-           else
+-             crop->combined_width = (uint32_t)zwidth;
+-           break;
++          uaux = (uint32_t)(offsets.crop_width * 1.0 * (seg - 1) / total);
++          if (uaux <= offsets.endx) {
++              crop->regionlist[i].x2 = offsets.endx - uaux;
++          } else {
++              crop->regionlist[i].x2 = 0;
++          }
++          if (crop->regionlist[i].x2 < offsets.startx) {
++              crop->regionlist[i].x2 = offsets.startx;
++          }
++          zwidth = crop->regionlist[i].x2 - crop->regionlist[i].x1 + 1;
++
++                /* This is passed to extractCropZone or extractCompositeZones */
++                crop->combined_length = (uint32_t)zlength;
++                if (crop->exp_mode == COMPOSITE_IMAGES)
++                        crop->combined_width += (uint32_t)zwidth;
++                else
++                        crop->combined_width = (uint32_t)zwidth;
++                break;
+       case EDGE_TOP: /* width from left, zones from top to bottom */
+       default:
+            zwidth = offsets.crop_width;
+@@ -5608,6 +5722,14 @@ getCropOffsets(struct image_data *image, struct crop_mask *crop, struct dump_opt
+            crop->regionlist[i].x2 = offsets.endx;
+
+            crop->regionlist[i].y1 = offsets.starty + (uint32_t)(offsets.crop_length * 1.0 * (seg - 1) / total);
++           if (crop->regionlist[i].y1 > offsets.endy) {
++               crop->regionlist[i].y1 = offsets.endy;
++           } else if (crop->regionlist[i].y1 >= image->length) {
++               crop->regionlist[i].y1 = image->length - 1;
++           }
++
++           /* FAULT: IMHO from here on, the calculation of y2 are based on wrong assumtions. The whole image is assumed and 'endy' and 'starty' are not respected anymore!*/
++           /* OLD Code:
+            test = offsets.starty + (uint32_t)(offsets.crop_length * 1.0 * seg / total);
+            if (test < 1 )
+              crop->regionlist[i].y2 = 0;
+@@ -5618,6 +5740,18 @@ getCropOffsets(struct image_data *image, struct crop_mask *crop, struct dump_opt
+              else
+              crop->regionlist[i].y2 = test - 1;
+            }
++           */
++                 /* NEW PROPOSED Code: Assumption: offsets are within image with top left corner as origin (0,0) and 'start' <= 'end'. */
++                 crop->regionlist[i].y2 = offsets.starty + (uint32_t)(offsets.crop_length * 1.0 * seg / total);
++           if (crop->regionlist[i].y2 > 0)crop->regionlist[i].y2 = crop->regionlist[i].y2 - 1;
++                 if (crop->regionlist[i].y2 < crop->regionlist[i].y1) {
++                         crop->regionlist[i].y2 = crop->regionlist[i].y1;
++                 } else if (crop->regionlist[i].y2 > offsets.endy) {
++                         crop->regionlist[i].y2 = offsets.endy;
++                 } else if (crop->regionlist[i].y2 >= image->length) {
++                         crop->regionlist[i].y2 = image->length - 1;
++                 }
++
+            zlength = crop->regionlist[i].y2 - crop->regionlist[i].y1 + 1;
+
+          /* This is passed to extractCropZone or extractCompositeZones */
+@@ -7551,7 +7685,8 @@ processCropSelections(struct image_data *image, struct crop_mask *crop,
+     total_width = total_length = 0;
+     for (i = 0; i < crop->selections; i++)
+       {
+-      cropsize = crop->bufftotal;
++
++        cropsize = crop->bufftotal;
+       crop_buff = seg_buffs[i].buffer;
+       if (!crop_buff)
+         crop_buff = (unsigned char *)limitMalloc(cropsize);
+@@ -7640,6 +7775,9 @@ processCropSelections(struct image_data *image, struct crop_mask *crop,
+
+       if (crop->crop_mode & CROP_ROTATE) /* rotate should be last as it can reallocate the buffer */
+         {
++          /* rotateImage() changes image->width, ->length, ->xres and ->yres, what it schouldn't do here, when more than one section is processed.
++           * ToDo: Therefore rotateImage() and its usage has to be reworked (e.g. like mirrorImage()) !!
++           */
+       if (rotateImage(crop->rotation, image, &crop->regionlist[i].width,
+                       &crop->regionlist[i].length, &crop_buff))
+           {
+@@ -7655,8 +7793,8 @@ processCropSelections(struct image_data *image, struct crop_mask *crop,
+         seg_buffs[i].size = (((crop->regionlist[i].width * image->bps + 7 ) / 8)
+                                * image->spp) * crop->regionlist[i].length;
+         }
+-      }
+-    }
++      }  /* for crop->selections loop */
++    }  /* Separated Images (else case) */
+   return (0);
+   } /* end processCropSelections */
+
+--
+2.33.0
+
diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2022-2953.patch b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-2953.patch
new file mode 100644
index 0000000000..3a3a915688
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-2953.patch
@@ -0,0 +1,87 @@
+CVE: CVE-2022-2953
+Upstream-Status: Backport
+Signed-off-by: Ross Burton <ross.burton@...>
+Signed-off-by: Zheng Qiu <zheng.qiu@...>
+
+From 8fe3735942ea1d90d8cef843b55b3efe8ab6feaf Mon Sep 17 00:00:00 2001
+From: Su_Laus <sulau@...>
+Date: Mon, 15 Aug 2022 22:11:03 +0200
+Subject: [PATCH] =?UTF-8?q?According=20to=20Richard=20Nolde=20https://gitl?=
+ =?UTF-8?q?ab.com/libtiff/libtiff/-/issues/401#note=5F877637400=20the=20ti?=
+ =?UTF-8?q?ffcrop=20option=20=E2=80=9E-S=E2=80=9C=20is=20also=20mutually?=
+ =?UTF-8?q?=20exclusive=20to=20the=20other=20crop=20options=20(-X|-Y),=20-?=
+ =?UTF-8?q?Z=20and=20-z.?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This is now checked and ends tiffcrop if those arguments are not mutually exclusive.
+
+This MR will fix the following tiffcrop issues: #349, #414, #422, #423, #424
+---
+ tools/tiffcrop.c | 31 ++++++++++++++++---------------
+ 1 file changed, 16 insertions(+), 15 deletions(-)
+
+diff --git a/tools/tiffcrop.c b/tools/tiffcrop.c
+index 90286a5e..c3b758ec 100644
+--- a/tools/tiffcrop.c
++++ b/tools/tiffcrop.c
+@@ -173,12 +173,12 @@ static   char tiffcrop_rev_date[] = "02-09-2022";
+ #define ROTATECW_270 32
+ #define ROTATE_ANY (ROTATECW_90 | ROTATECW_180 | ROTATECW_270)
+
+-#define CROP_NONE     0
+-#define CROP_MARGINS  1
+-#define CROP_WIDTH    2
+-#define CROP_LENGTH   4
+-#define CROP_ZONES    8
+-#define CROP_REGIONS 16
++#define CROP_NONE     0     /* "-S" -> Page_MODE_ROWSCOLS and page->rows/->cols != 0 */
++#define CROP_MARGINS  1     /* "-m" */
++#define CROP_WIDTH    2     /* "-X" */
++#define CROP_LENGTH   4     /* "-Y" */
++#define CROP_ZONES    8     /* "-Z" */
++#define CROP_REGIONS 16     /* "-z" */
+ #define CROP_ROTATE  32
+ #define CROP_MIRROR  64
+ #define CROP_INVERT 128
+@@ -316,7 +316,7 @@ struct crop_mask {
+ #define PAGE_MODE_RESOLUTION   1
+ #define PAGE_MODE_PAPERSIZE    2
+ #define PAGE_MODE_MARGINS      4
+-#define PAGE_MODE_ROWSCOLS     8
++#define PAGE_MODE_ROWSCOLS     8    /* for -S option */
+
+ #define INVERT_DATA_ONLY      10
+ #define INVERT_DATA_AND_TAG   11
+@@ -781,7 +781,7 @@ static const char usage_info[] =
+ "             The four debug/dump options are independent, though it makes little sense to\n"
+ "             specify a dump file without specifying a detail level.\n"
+ "\n"
+-"Note:        The (-X|-Y), -Z and -z options are mutually exclusive.\n"
++"Note:        The (-X|-Y), -Z, -z and -S options are mutually exclusive.\n"
+ "             In no case should the options be applied to a given selection successively.\n"
+ "\n"
+ ;
+@@ -2131,13 +2131,14 @@ void  process_command_opts (int argc, char *argv[], char *mp, char *mode, uint32
+               /*NOTREACHED*/
+       }
+     }
+-    /*-- Check for not allowed combinations (e.g. -X, -Y and -Z and -z are mutually exclusive) --*/
+-    char XY, Z, R;
++    /*-- Check for not allowed combinations (e.g. -X, -Y and -Z, -z and -S are mutually exclusive) --*/
++    char XY, Z, R, S;
+     XY = ((crop_data->crop_mode & CROP_WIDTH) || (crop_data->crop_mode & CROP_LENGTH));
+     Z = (crop_data->crop_mode & CROP_ZONES);
+     R = (crop_data->crop_mode & CROP_REGIONS);
+-    if ((XY && Z) || (XY && R) || (Z && R)) {
+-        TIFFError("tiffcrop input error", "The crop options(-X|-Y), -Z and -z are mutually exclusive.->Exit");
++    S = (page->mode & PAGE_MODE_ROWSCOLS);
++    if ((XY && Z) || (XY && R) || (XY && S) || (Z && R) || (Z && S) || (R && S)) {
++        TIFFError("tiffcrop input error", "The crop options(-X|-Y), -Z, -z and -S are mutually exclusive.->Exit");
+         exit(EXIT_FAILURE);
+     }
+   }  /* end process_command_opts */
+--
+2.34.1
+
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
index f84057c46b..29a2c38d8e 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
@@ -25,6 +25,8 @@ SRC_URI = "http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
            file://CVE-2022-2869.patch \
            file://CVE-2022-2867.patch \
            file://b258ed69a485a9cfb299d9f060eb2a46c54e5903.patch \
+           file://0001-tiffcrop-Fix-issue-330-and-some-more-from-320-to-349.patch \
+           file://CVE-2022-2953.patch \
            "

 SRC_URI[sha256sum] = "0e46e5acb087ce7d1ac53cf4f56a09b221537fc86dfc5daaad1c2e89e1b37ac8"
--
2.25.1





Re: [PATCH 2/2] gstreamer1.0-plugins-good: use libsoup-3.0 by default

Markus Volk
 

Am So, 6. Nov 2022 um 23:12:40 +0100 schrieb Alexandre Belloni via lists.openembedded.org <alexandre.belloni=bootlin.com@...>:
WARNING: gstreamer1.0-meta-base-1.0-r0 do_package_qa: QA Issue: gstreamer1.0-meta-base rdepends on gstreamer1.0-plugins-good-soup, but it isn't a build dependency? [build-deps]

Hello,

i've sent a v2 for this patch that should fix the issue.


[PATCHv2] gstreamer1.0-plugins-good: use libsoup-3.0 by default

Markus Volk
 

- add a PACKAGECONFIG for soup3
- add PACKAGECONFIG_SOUP variable as it is used in webkitgtk and epiphany

Signed-off-by: Markus Volk <f_l_k@...>
---
.../gstreamer/gstreamer1.0-plugins-good_1.20.3.bb | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_=
1.20.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1=
.20.3.bb
index 0235935a4a..9dd629eaa0 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.3.=
bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.3.=
bb
@@ -20,11 +20,14 @@ DEPENDS +=3D "gstreamer1.0-plugins-base libcap zlib"
RPROVIDES:${PN}-pulseaudio +=3D "${PN}-pulse"
RPROVIDES:${PN}-soup +=3D "${PN}-souphttpsrc"
=20
+PACKAGECONFIG_SOUP ?=3D "soup3"
+
PACKAGECONFIG ??=3D " \
${GSTREAMER_ORC} \
+ ${PACKAGECONFIG_SOUP} \
${@bb.utils.filter('DISTRO_FEATURES', 'pulseaudio x11', d)} \
${@bb.utils.contains('TUNE_FEATURES', 'm64', 'asm', '', d)} \
- bz2 cairo flac gdk-pixbuf gudev jpeg lame libpng mpg123 soup speex t=
aglib v4l2 \
+ bz2 cairo flac gdk-pixbuf gudev jpeg lame libpng mpg123 speex taglib=
v4l2 \
"
=20
X11DEPENDS =3D "virtual/libx11 libsm libxrender libxfixes libxdamage"
@@ -53,8 +56,9 @@ PACKAGECONFIG[qt5] =3D "-Dqt5=3Denabled,-Dqt5=3D=
disabled,qtbase qtdeclarative q
# instead of linking to it. And instead of using the default libsoup C h=
eaders, it
# uses its own stub header. Consequently, objdump will not show the libs=
oup .so as
# a dependency, and libsoup won't be added to an image. Fix this by sett=
ing libsoup
-# as RDEPEND instead of DEPEND.
-PACKAGECONFIG[soup] =3D "-Dsoup=3Denabled,-Dsoup=3Ddisabled,,libso=
up-2.4"
+# as RDEPEND.
+PACKAGECONFIG[soup2] =3D "-Dsoup=3Denabled,,libsoup-2.4,libsoup-2.4,,sou=
p3"
+PACKAGECONFIG[soup3] =3D "-Dsoup=3Denabled,,libsoup,libsoup,,soup2"
PACKAGECONFIG[speex] =3D "-Dspeex=3Denabled,-Dspeex=3Ddisabled,spee=
x"
PACKAGECONFIG[rpi] =3D "-Drpicamsrc=3Denabled,-Drpicamsrc=3Ddisab=
led,userland"
PACKAGECONFIG[taglib] =3D "-Dtaglib=3Denabled,-Dtaglib=3Ddisabled,ta=
glib"
--=20
2.34.1


[dunfell][PATCH] bluez: CVE-2022-3637 A DoS exists in monitor/jlink.c

Hitendra Prajapati
 

Upstream-Status: Backport from https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/monitor/jlink.c?id=1d6cfb8e625a944010956714c1802bc1e1fc6c4f

Signed-off-by: Hitendra Prajapati <hprajapati@...>
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
.../bluez5/bluez5/CVE-2022-3637.patch | 39 +++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3637.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index eaac9ee849..0ef3192c77 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -57,6 +57,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
file://CVE-2021-3658.patch \
file://CVE-2022-0204.patch \
file://CVE-2022-39176.patch \
+ file://CVE-2022-3637.patch \
"
S = "${WORKDIR}/bluez-${PV}"

diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3637.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3637.patch
new file mode 100644
index 0000000000..4ca60f99d5
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3637.patch
@@ -0,0 +1,39 @@
+From b808b2852a0b48c6f9dbb038f932613cea3126c2 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati <hprajapati@...>
+Date: Thu, 27 Oct 2022 09:51:27 +0530
+Subject: [PATCH] CVE-2022-3637
+
+Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/monitor/jlink.c?id=1d6cfb8e625a944010956714c1802bc1e1fc6c4f]
+CVE: CVE-2022-3637
+Signed-off-by: Hitendra Prajapati <hprajapati@...>
+
+monitor: Fix crash when using RTT backend
+
+This fix regression introduced by "monitor: Fix memory leaks".
+J-Link shared library is in use if jlink_init() returns 0 and thus
+handle shall not be closed.
+---
+ monitor/jlink.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/monitor/jlink.c b/monitor/jlink.c
+index afa9d93..5bd4aed 100644
+--- a/monitor/jlink.c
++++ b/monitor/jlink.c
+@@ -120,9 +120,12 @@ int jlink_init(void)
+ !jlink.tif_select || !jlink.setspeed ||
+ !jlink.connect || !jlink.getsn ||
+ !jlink.emu_getproductname ||
+- !jlink.rtterminal_control || !jlink.rtterminal_read)
++ !jlink.rtterminal_control || !jlink.rtterminal_read) {
++ dlclose(so);
+ return -EIO;
++ }
+
++ /* don't dlclose(so) here cause symbols from it are in use now */
+ return 0;
+ }
+
+--
+2.25.1
+
--
2.25.1


[kirkstone][PATCH] bluez: CVE-2022-3563 Fix null pointer derefference

Hitendra Prajapati
 

Upstream-Status: Backport from https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=e3c92f1f786f0b55440bd908b55894d0c792cf0e

Signed-off-by: Hitendra Prajapati <hprajapati@...>
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
.../bluez5/bluez5/CVE-2022-3563.patch | 44 +++++++++++++++++++
2 files changed, 45 insertions(+)
create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3563.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index 07d36ab74b..a9989585f5 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -54,6 +54,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
file://0001-test-gatt-Fix-hung-issue.patch \
file://CVE-2022-3637.patch \
+ file://CVE-2022-3563.patch \
"
S = "${WORKDIR}/bluez-${PV}"

diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3563.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3563.patch
new file mode 100644
index 0000000000..e67e7093ec
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3563.patch
@@ -0,0 +1,44 @@
+From 5e22473411bbd673b588d9f3d9d130199be13b4b Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati <hprajapati@...>
+Date: Fri, 4 Nov 2022 17:09:57 +0530
+Subject: [PATCH] CVE-2022-3563
+
+Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=e3c92f1f786f0b55440bd908b55894d0c792cf0e]
+CVE: CVE-2022-3563
+Signed-off-by: Hitendra Prajapati <hprajapati@...>
+
+mgmt-tester: Fix null dereference issue reported by scan-build
+This patch fixes the null dereference reported by the scan-build.
+
+tools/mgmt-tester.c:12025:28: warning: Access to field 'cap_len' results
+in a dereference of a null pointer (loaded from variable 'rp')
+[core.NullDereference]
+
+ if (sizeof(rp->cap_len) + rp->cap_len != length) {
+ ^~~~~~~~~~~
+---
+ tools/mgmt-tester.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/tools/mgmt-tester.c b/tools/mgmt-tester.c
+index e5319d1..b15ed5e 100644
+--- a/tools/mgmt-tester.c
++++ b/tools/mgmt-tester.c
+@@ -11960,12 +11960,14 @@ static void read_50_controller_cap_complete(uint8_t status, uint16_t length,
+ tester_warn("Failed to read advertising features: %s (0x%02x)",
+ mgmt_errstr(status), status);
+ tester_test_failed();
++ return;
+ }
+
+ if (sizeof(rp->cap_len) + rp->cap_len != length) {
+ tester_warn("Controller capabilities malformed, size %zu != %u",
+ sizeof(rp->cap_len) + rp->cap_len, length);
+ tester_test_failed();
++ return;
+ }
+
+ while (offset < rp->cap_len) {
+--
+2.25.1
+
--
2.25.1


[kirkstone][PATCH] bluez: CVE-2022-3637 A DoS exists in monitor/jlink.c

Hitendra Prajapati
 

Upstream-Status: Backport from https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/monitor/jlink.c?id=1d6cfb8e625a944010956714c1802bc1e1fc6c4f

Signed-off-by: Hitendra Prajapati <hprajapati@...>
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
.../bluez5/bluez5/CVE-2022-3637.patch | 39 +++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3637.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index 79d4645ca8..07d36ab74b 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -53,6 +53,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \
file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
file://0001-test-gatt-Fix-hung-issue.patch \
+ file://CVE-2022-3637.patch \
"
S = "${WORKDIR}/bluez-${PV}"

diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3637.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3637.patch
new file mode 100644
index 0000000000..5bd00ddca5
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-3637.patch
@@ -0,0 +1,39 @@
+From 8b8a8f76b64a72ddc78f9052f80c87c0da72bcc6 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati <hprajapati@...>
+Date: Thu, 3 Nov 2022 11:56:44 +0530
+Subject: [PATCH] CVE-2022-3637
+
+Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/monitor/jlink.c?id=1d6cfb8e625a944010956714c1802bc1e1fc6c4f]
+CVE: CVE-2022-3637
+Signed-off-by: Hitendra Prajapati <hprajapati@...>
+
+monitor: Fix crash when using RTT backend
+
+This fix regression introduced by "monitor: Fix memory leaks".
+J-Link shared library is in use if jlink_init() returns 0 and thus
+handle shall not be closed.
+---
+ monitor/jlink.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/monitor/jlink.c b/monitor/jlink.c
+index 9aaa4eb..f9d4037 100644
+--- a/monitor/jlink.c
++++ b/monitor/jlink.c
+@@ -107,9 +107,12 @@ int jlink_init(void)
+ !jlink.tif_select || !jlink.setspeed ||
+ !jlink.connect || !jlink.getsn ||
+ !jlink.emu_getproductname ||
+- !jlink.rtterminal_control || !jlink.rtterminal_read)
++ !jlink.rtterminal_control || !jlink.rtterminal_read) {
++ dlclose(so);
+ return -EIO;
++ }
+
++ /* don't dlclose(so) here cause symbols from it are in use now */
+ return 0;
+ }
+
+--
+2.25.1
+
--
2.25.1


Re: [master][kirkstone][PATCH V2] rng-tools: Add Arm aarch64 CPU specific configuration to address excessive CPU usage on startup

Xiangyu Chen
 

On 11/7/22 10:18, Khem Raj 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.

On Sun, Nov 6, 2022 at 5:21 PM Xiangyu Chen <xiangyu.chen@...> wrote:

On 11/1/22 09:48, Xiangyu Chen wrote:
With the default jitter options aarch64 CPU-based devices typically experience continuous
high CPU utilisation for several minutes after rngd starts.

Accoring to the rng-tools issue #150[1] and comments[2],in order to address this,
the following configuration changes have been made, those configurations
also can be found on Alpine Linux[3]:

- reduce the number of threads used to 1 in total, rather than 1 per core.
- reduce the buffer size from 16535 to 4133 which reduces the time taken
to fill the buffer (and so reduces the duration of CPU load).

[1] https://github.com/nhorman/rng-tools/issues/150
[2] https://github.com/nhorman/rng-tools/issues/150#issuecomment-953079212
[3] https://git.alpinelinux.org/aports/tree/main/rng-tools/rngd.confd-arm

Signed-off-by: Xiangyu Chen <xiangyu.chen@...>
---
Changes in V2:
*put the aarch64 specific default file in meta/recipes-support/rng-tools/rng-tools/aarch64
Friendly ping. Is there any more concern on this?
My concern is that will it be so for all aarch64 machines ?
I tested two aarch64 platforms on my hand, zynqmp and raspi4, the rng-tools behavior is the same, when service start, the jitter random generator would load full cpu cores load. It would cause other services take long time to start. I also checked another linux distribution, so far, only Alpine Linux processed this issue and it applied those configurations on all aarch64 platforms.


Thanks,

Xiangyu



Thanks,

Xiangyu

---
.../rng-tools/rng-tools/aarch64/default | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 meta/recipes-support/rng-tools/rng-tools/aarch64/default

diff --git a/meta/recipes-support/rng-tools/rng-tools/aarch64/default b/meta/recipes-support/rng-tools/rng-tools/aarch64/default
new file mode 100644
index 0000000000..5a2fbcc9ef
--- /dev/null
+++ b/meta/recipes-support/rng-tools/rng-tools/aarch64/default
@@ -0,0 +1,11 @@
+# With the default jitter options Arm CPU-based devices typically experience
+# continuous high CPU utilisation for several minutes after rngd starts.
+# See https://gitlab.alpinelinux.org/alpine/aports/-/issues/13035 and
+# https://github.com/nhorman/rng-tools/issues/150
+# In order to address this the following configuration changes have been made:
+#
+# - reduce the number of threads used to 1 in total, rather than 1 per core.
+# - reduce the buffer size from 16535 to 4133 which reduces the time taken
+# to fill the buffer (and so reduces the duration of CPU load).
+#
+EXTRA_ARGS="-r /dev/hwrng -O jitter:buffer_size:4133 -O jitter:refill_thresh:4133 -O jitter:thread_count:1"



Re: [master][kirkstone][PATCH V2] rng-tools: Add Arm aarch64 CPU specific configuration to address excessive CPU usage on startup

Khem Raj
 

On Sun, Nov 6, 2022 at 5:21 PM Xiangyu Chen <xiangyu.chen@...> wrote:


On 11/1/22 09:48, Xiangyu Chen wrote:
With the default jitter options aarch64 CPU-based devices typically experience continuous
high CPU utilisation for several minutes after rngd starts.

Accoring to the rng-tools issue #150[1] and comments[2],in order to address this,
the following configuration changes have been made, those configurations
also can be found on Alpine Linux[3]:

- reduce the number of threads used to 1 in total, rather than 1 per core.
- reduce the buffer size from 16535 to 4133 which reduces the time taken
to fill the buffer (and so reduces the duration of CPU load).

[1] https://github.com/nhorman/rng-tools/issues/150
[2] https://github.com/nhorman/rng-tools/issues/150#issuecomment-953079212
[3] https://git.alpinelinux.org/aports/tree/main/rng-tools/rngd.confd-arm

Signed-off-by: Xiangyu Chen <xiangyu.chen@...>
---
Changes in V2:
*put the aarch64 specific default file in meta/recipes-support/rng-tools/rng-tools/aarch64
Friendly ping. Is there any more concern on this?
My concern is that will it be so for all aarch64 machines ?



Thanks,

Xiangyu

---
.../rng-tools/rng-tools/aarch64/default | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 meta/recipes-support/rng-tools/rng-tools/aarch64/default

diff --git a/meta/recipes-support/rng-tools/rng-tools/aarch64/default b/meta/recipes-support/rng-tools/rng-tools/aarch64/default
new file mode 100644
index 0000000000..5a2fbcc9ef
--- /dev/null
+++ b/meta/recipes-support/rng-tools/rng-tools/aarch64/default
@@ -0,0 +1,11 @@
+# With the default jitter options Arm CPU-based devices typically experience
+# continuous high CPU utilisation for several minutes after rngd starts.
+# See https://gitlab.alpinelinux.org/alpine/aports/-/issues/13035 and
+# https://github.com/nhorman/rng-tools/issues/150
+# In order to address this the following configuration changes have been made:
+#
+# - reduce the number of threads used to 1 in total, rather than 1 per core.
+# - reduce the buffer size from 16535 to 4133 which reduces the time taken
+# to fill the buffer (and so reduces the duration of CPU load).
+#
+EXTRA_ARGS="-r /dev/hwrng -O jitter:buffer_size:4133 -O jitter:refill_thresh:4133 -O jitter:thread_count:1"




Re: [master][kirkstone][PATCH V2] rng-tools: Add Arm aarch64 CPU specific configuration to address excessive CPU usage on startup

Xiangyu Chen
 

On 11/1/22 09:48, Xiangyu Chen wrote:
With the default jitter options aarch64 CPU-based devices typically experience continuous
high CPU utilisation for several minutes after rngd starts.

Accoring to the rng-tools issue #150[1] and comments[2],in order to address this,
the following configuration changes have been made, those configurations
also can be found on Alpine Linux[3]:

- reduce the number of threads used to 1 in total, rather than 1 per core.
- reduce the buffer size from 16535 to 4133 which reduces the time taken
to fill the buffer (and so reduces the duration of CPU load).

[1] https://github.com/nhorman/rng-tools/issues/150
[2] https://github.com/nhorman/rng-tools/issues/150#issuecomment-953079212
[3] https://git.alpinelinux.org/aports/tree/main/rng-tools/rngd.confd-arm

Signed-off-by: Xiangyu Chen <xiangyu.chen@...>
---
Changes in V2:
*put the aarch64 specific default file in meta/recipes-support/rng-tools/rng-tools/aarch64
Friendly ping. Is there any more concern on this?


Thanks,

Xiangyu

---
.../rng-tools/rng-tools/aarch64/default | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 meta/recipes-support/rng-tools/rng-tools/aarch64/default

diff --git a/meta/recipes-support/rng-tools/rng-tools/aarch64/default b/meta/recipes-support/rng-tools/rng-tools/aarch64/default
new file mode 100644
index 0000000000..5a2fbcc9ef
--- /dev/null
+++ b/meta/recipes-support/rng-tools/rng-tools/aarch64/default
@@ -0,0 +1,11 @@
+# With the default jitter options Arm CPU-based devices typically experience
+# continuous high CPU utilisation for several minutes after rngd starts.
+# See https://gitlab.alpinelinux.org/alpine/aports/-/issues/13035 and
+# https://github.com/nhorman/rng-tools/issues/150
+# In order to address this the following configuration changes have been made:
+#
+# - reduce the number of threads used to 1 in total, rather than 1 per core.
+# - reduce the buffer size from 16535 to 4133 which reduces the time taken
+# to fill the buffer (and so reduces the duration of CPU load).
+#
+EXTRA_ARGS="-r /dev/hwrng -O jitter:buffer_size:4133 -O jitter:refill_thresh:4133 -O jitter:thread_count:1"