Re: [OE-core][kirkstone][PATCH] Fix kirkstone dmidedecode smbios3_decode
On Sat, 2023-08-12 at 09:47 +0800, Lau, Karn Jye wrote:
> From: "Lau, Karn Jye"
>
> Recent CVE fixes in kirkstone dmidecode broke it
> functionality, this issue is only observed in kirkstone
> version of dmidecode(v3.3).Update smbios3_decode to address
> the broken functionality.
>
> Signed-off-by: Lau, Karn Jye
> ---
> ...mbios3_decode-in-kirkstone-dmidecode.patch | 125
> ++
> .../dmidecode/dmidecode_3.3.bb | 1 +
> 2 files changed, 126 insertions(+)
> create mode 100644 meta/recipes-devtools/dmidecode/dmidecode/0002-
> Fix-smbios3_decode-in-kirkstone-dmidecode.patch
>
> diff --git a/meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-
> smbios3_decode-in-kirkstone-dmidecode.patch b/meta/recipes-
> devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-
> dmidecode.patch
> new file mode 100644
> index 00..00ffb90ce2
> --- /dev/null
> +++ b/meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-
> smbios3_decode-in-kirkstone-dmidecode.patch
> @@ -0,0 +1,125 @@
> +From 8a395982d6f350d0744666cffe42c4a486656c6f Mon Sep 17 00:00:00
> 2001
> +From: "Lau, Karn Jye"
> +Date: Sat, 12 Aug 2023 08:41:58 +0800
> +Subject: [PATCH 2/2] Fix smbios3_decode in kirkstone dmidecode
> +
> +Recent CVE fix broke dmidecode functionality,
> +port upstream changes to fix smbios3_decodein
> +function.
> +
> +Reference:
> https://github.com/mirror/dmidecode/commit/39b2dd7b6ab719b920e96ed832
> cfb4bdd664e808
Why are we backporting only a part of this commit?
Thanks,
Anuj
> +
> +Signed-off-by: Lau, Karn Jye
> +---
> + dmidecode.c | 81
> +++--
> + 1 file changed, 79 insertions(+), 2 deletions(-)
> +
> +diff --git a/dmidecode.c b/dmidecode.c
> +index f826f6c..91e1a32 100644
> +--- a/dmidecode.c
> b/dmidecode.c
> +@@ -3514,6 +3514,72 @@ static const char
> *dmi_power_supply_range_switching(u8 code)
> + return out_of_spec;
> + }
> +
> ++/* Allocates a buffer for the table, must be freed by the caller */
> ++static u8 *dmi_table_get(off_t base, u32 *len, u16 num, u32 ver,
> ++ const char *devmem, u32 flags)
> ++{
> ++ u8 *buf;
> ++
> ++ if (ver > SUPPORTED_SMBIOS_VER && !(opt.flags & FLAG_QUIET))
> ++ {
> ++ pr_comment("SMBIOS implementations newer than version
> %u.%u.%u are not",
> ++ SUPPORTED_SMBIOS_VER >> 16,
> ++ (SUPPORTED_SMBIOS_VER >> 8) & 0xFF,
> ++ SUPPORTED_SMBIOS_VER & 0xFF);
> ++ pr_comment("fully supported by this version of
> dmidecode.");
> ++ }
> ++
> ++ if (!(opt.flags & FLAG_QUIET))
> ++ {
> ++ if (opt.type == NULL)
> ++ {
> ++ if (num)
> ++ pr_info("%u structures occupying %u
> bytes.",
> ++ num, *len);
> ++ if (!(opt.flags & FLAG_FROM_DUMP))
> ++ pr_info("Table at 0x%08llX.",
> ++ (unsigned long long)base);
> ++ }
> ++ pr_sep();
> ++ }
> ++
> ++ if ((flags & FLAG_NO_FILE_OFFSET) || (opt.flags &
> FLAG_FROM_DUMP))
> ++ {
> ++ /*
> ++ * When reading from sysfs or from a dump file, the
> file may be
> ++ * shorter than announced. For SMBIOS v3 this is
> expcted, as we
> ++ * only know the maximum table size, not the actual
> table size.
> ++ * For older implementations (and for SMBIOS v3 too),
> this
> ++ * would be the result of the kernel truncating the
> table on
> ++ * parse error.
> ++ */
> ++ size_t size = *len;
> ++ buf = read_file(flags & FLAG_NO_FILE_OFFSET ? 0 :
> base,
> ++ , devmem);
> ++ if (!(opt.flags & FLAG_QUIET) && num && size !=
> (size_t)*len)
> ++ {
> ++ fprintf(stderr, "Wrong DMI structures length:
> %u bytes "
> ++ "announced, only %lu bytes
> available.\n",
> ++ *len, (unsigned long)size);
> ++ }
> ++ *len = size;
> ++ }
> ++ else
> ++ buf = mem_chunk(base, *len, devmem);
> ++
> ++ if (buf == NULL)
> ++ {
> ++ fprintf(stderr, "Failed to read table, sorry.\n");
> ++#ifndef USE_MMAP
> ++ if (!(flags & FLAG_NO_FILE_OFFSET))
> ++ fprintf(stderr,
> ++ "Try compiling dmidecode with -
> DUSE_MMAP.\n");
> ++#endif
> ++ }
> ++
> ++ return buf;
> ++}
> ++
> + /*
> + * 7.41 Additional Information (Type 40)
> + *
> +@@ -5428,8 +5494,11 @@ static int smbios3_decode(u8 *buf, size_t
> buf_len, const char *devmem, u32 flags
> + return 0;
> + }
> +
> +- dmi_table(((off_t)offset.h
Re: [OE-core][kirkstone][PATCH] openssl: Backport fix CVE-2023-2975
Hi Ashish,
This CVE and a couple of others were previously fixed with a
bug/security fix version bump:
https://git.openembedded.org/openembedded-core/commit/?h=kirkstone=94ce10791ce10aa30d3a3bdef53f9b2f3c1b331a
Steve
On Mon, Aug 14, 2023 at 6:19 AM Ashish Sharma wrote:
>
> Signed-off-by: Ashish Sharma
> ---
> .../openssl/openssl/CVE-2023-2975.patch | 61 +++
> .../openssl/openssl_3.0.9.bb | 1 +
> 2 files changed, 62 insertions(+)
> create mode 100644
> meta/recipes-connectivity/openssl/openssl/CVE-2023-2975.patch
>
> diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2023-2975.patch
> b/meta/recipes-connectivity/openssl/openssl/CVE-2023-2975.patch
> new file mode 100644
> index 000..fe78e87a831
> --- /dev/null
> +++ b/meta/recipes-connectivity/openssl/openssl/CVE-2023-2975.patch
> @@ -0,0 +1,61 @@
> +From 00e2f5eea29994d19293ec4e8c8775ba73678598 Mon Sep 17 00:00:00 2001
> +From: Tomas Mraz
> +Date: Tue, 4 Jul 2023 17:30:35 +0200
> +Subject: [PATCH] Do not ignore empty associated data with AES-SIV mode
> +
> +The AES-SIV mode allows for multiple associated data items
> +authenticated separately with any of these being 0 length.
> +
> +The provided implementation ignores such empty associated data
> +which is incorrect in regards to the RFC 5297 and is also
> +a security issue because such empty associated data then become
> +unauthenticated if an application expects to authenticate them.
> +
> +Fixes CVE-2023-2975
> +
> +Reviewed-by: Matt Caswell
> +Reviewed-by: Paul Dale
> +(Merged from https://github.com/openssl/openssl/pull/21384)
> +
> +(cherry picked from commit c426c281cfc23ab182f7d7d7a35229e7db1494d9)
> +
> +Upstream-Status: Backport
> [https://git.openssl.org/gitweb/?p=openssl.git;a=patch;h=00e2f5eea29994d19293ec4e8c8775ba73678598]
> +CVE: CVE-2023-2975
> +Signed-off-by: Ashish Sharma
> +
> + .../implementations/ciphers/cipher_aes_siv.c | 18 +++---
> + 1 file changed, 11 insertions(+), 7 deletions(-)
> +
> +diff --git a/providers/implementations/ciphers/cipher_aes_siv.c
> b/providers/implementations/ciphers/cipher_aes_siv.c
> +index 45010b90db..b396c8651a 100644
> +--- a/providers/implementations/ciphers/cipher_aes_siv.c
> b/providers/implementations/ciphers/cipher_aes_siv.c
> +@@ -120,14 +120,18 @@ static int siv_cipher(void *vctx, unsigned char *out,
> size_t *outl,
> + if (!ossl_prov_is_running())
> + return 0;
> +
> +-if (inl == 0) {
> +-*outl = 0;
> +-return 1;
> +-}
> ++/* Ignore just empty encryption/decryption call and not AAD. */
> ++if (out != NULL) {
> ++if (inl == 0) {
> ++if (outl != NULL)
> ++*outl = 0;
> ++return 1;
> ++}
> +
> +-if (outsize < inl) {
> +-ERR_raise(ERR_LIB_PROV, PROV_R_OUTPUT_BUFFER_TOO_SMALL);
> +-return 0;
> ++if (outsize < inl) {
> ++ERR_raise(ERR_LIB_PROV, PROV_R_OUTPUT_BUFFER_TOO_SMALL);
> ++return 0;
> ++}
> + }
> +
> + if (ctx->hw->cipher(ctx, out, in, inl) <= 0)
> +--
> +2.34.1
> +
> diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.9.bb
> b/meta/recipes-connectivity/openssl/openssl_3.0.9.bb
> index 849bd7e5a69..61e81cfa09d 100644
> --- a/meta/recipes-connectivity/openssl/openssl_3.0.9.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_3.0.9.bb
> @@ -12,6 +12,7 @@ SRC_URI =
> "http://www.openssl.org/source/openssl-${PV}.tar.gz \
>
> file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
> file://afalg.patch \
> file://0001-Configure-do-not-tweak-mips-cflags.patch \
> + file://CVE-2023-2975.patch \
> "
>
> SRC_URI:append:class-nativesdk = " \
> --
> 2.35.7
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185942):
https://lists.openembedded.org/g/openembedded-core/message/185942
Mute This Topic: https://lists.openembedded.org/mt/100740204/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] Fix kirkstone dmidedecode smbios3_decode
Thanks for the patch. Unfortunately there is an issue:
Applying patch 0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
patching file dmidecode.c
Hunk #1 succeeded at 3513 (offset -1 lines).
Hunk #2 succeeded at 5443 (offset -51 lines).
Hunk #3 succeeded at 5461 with fuzz 2 (offset -48 lines).
Applying patch CVE-2023-30630_1.patch
patching file dmidecode.c
Hunk #1 succeeded at 5196 (offset -231 lines).
Hunk #2 succeeded at 5421 (offset -272 lines).
Hunk #3 succeeded at 5456 (offset -272 lines).
Hunk #4 succeeded at 5497 with fuzz 2 (offset -269 lines).
Hunk #5 succeeded at 5514 (offset -261 lines).
Hunk #6 succeeded at 5565 (offset -261 lines).
Hunk #7 succeeded at 5573 (offset -261 lines).
Hunk #8 succeeded at 5594 (offset -261 lines).
patching file util.c
patching file util.h
Could you please fix the fuzz error and submit a v2?
Also, a more standard shortlog would be something like:
dmidecode: fix smbios3_decode
Could you fix this also with v2?
Thanks again!
Steve
On Fri, Aug 11, 2023 at 3:50 PM Lau, Karn Jye wrote:
>
> From: "Lau, Karn Jye"
>
> Recent CVE fixes in kirkstone dmidecode broke it
> functionality, this issue is only observed in kirkstone
> version of dmidecode(v3.3).Update smbios3_decode to address
> the broken functionality.
>
> Signed-off-by: Lau, Karn Jye
> ---
> ...mbios3_decode-in-kirkstone-dmidecode.patch | 125 ++
> .../dmidecode/dmidecode_3.3.bb| 1 +
> 2 files changed, 126 insertions(+)
> create mode 100644
> meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
>
> diff --git
> a/meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
>
> b/meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
> new file mode 100644
> index 00..00ffb90ce2
> --- /dev/null
> +++
> b/meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
> @@ -0,0 +1,125 @@
> +From 8a395982d6f350d0744666cffe42c4a486656c6f Mon Sep 17 00:00:00 2001
> +From: "Lau, Karn Jye"
> +Date: Sat, 12 Aug 2023 08:41:58 +0800
> +Subject: [PATCH 2/2] Fix smbios3_decode in kirkstone dmidecode
> +
> +Recent CVE fix broke dmidecode functionality,
> +port upstream changes to fix smbios3_decodein
> +function.
> +
> +Reference:https://github.com/mirror/dmidecode/commit/39b2dd7b6ab719b920e96ed832cfb4bdd664e808
> +
> +Signed-off-by: Lau, Karn Jye
> +---
> + dmidecode.c | 81 +++--
> + 1 file changed, 79 insertions(+), 2 deletions(-)
> +
> +diff --git a/dmidecode.c b/dmidecode.c
> +index f826f6c..91e1a32 100644
> +--- a/dmidecode.c
> b/dmidecode.c
> +@@ -3514,6 +3514,72 @@ static const char
> *dmi_power_supply_range_switching(u8 code)
> + return out_of_spec;
> + }
> +
> ++/* Allocates a buffer for the table, must be freed by the caller */
> ++static u8 *dmi_table_get(off_t base, u32 *len, u16 num, u32 ver,
> ++ const char *devmem, u32 flags)
> ++{
> ++ u8 *buf;
> ++
> ++ if (ver > SUPPORTED_SMBIOS_VER && !(opt.flags & FLAG_QUIET))
> ++ {
> ++ pr_comment("SMBIOS implementations newer than version
> %u.%u.%u are not",
> ++ SUPPORTED_SMBIOS_VER >> 16,
> ++ (SUPPORTED_SMBIOS_VER >> 8) & 0xFF,
> ++ SUPPORTED_SMBIOS_VER & 0xFF);
> ++ pr_comment("fully supported by this version of dmidecode.");
> ++ }
> ++
> ++ if (!(opt.flags & FLAG_QUIET))
> ++ {
> ++ if (opt.type == NULL)
> ++ {
> ++ if (num)
> ++ pr_info("%u structures occupying %u bytes.",
> ++ num, *len);
> ++ if (!(opt.flags & FLAG_FROM_DUMP))
> ++ pr_info("Table at 0x%08llX.",
> ++ (unsigned long long)base);
> ++ }
> ++ pr_sep();
> ++ }
> ++
> ++ if ((flags & FLAG_NO_FILE_OFFSET) || (opt.flags & FLAG_FROM_DUMP))
> ++ {
> ++ /*
> ++ * When reading from sysfs or from a dump file, the file may
> be
> ++ * shorter than announced. For SMBIOS v3 this is expcted, as
> we
> ++ * only know the maximum table size, not the actual table
> size.
> ++ * For older implementations (and for SMBIOS v3 too), this
> ++ * would be the result of the kernel truncating the table on
> ++ * parse error.
> ++ */
> ++ size_t size = *len;
> ++ buf = read_file(flags & FLAG_NO_FILE_OFFSET ? 0 : base,
> ++ , devmem);
> ++ if (!(opt.flags & FLAG_QUIET) && num && size != (size_t)*len)
> ++ {
> ++ fprintf(stderr, "Wrong DMI structures length: %u
> bytes
Re: [OE-core] [yocto-security] OE-core CVE metrics for dunfell on Sun 13 Aug 2023 02:00:01 AM HST
On Mon, 2023-08-14 at 06:36 -1000, Steve Sakoman wrote: > On Sun, Aug 13, 2023 at 3:02 AM Richard Purdie > wrote: > > > > On Sun, 2023-08-13 at 02:28 -1000, Steve Sakoman wrote: > > > Branch: dunfell > > > > > > New this week: 5 CVEs > > > CVE-2023-29409 (CVSS3: 5.3 MEDIUM): go:go-native > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-29409 * > > > CVE-2023-3180 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 * > > > CVE-2023-3817 (CVSS3: 5.3 MEDIUM): openssl:openssl-native > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3817 * > > > CVE-2023-4016 (CVSS3: 5.5 MEDIUM): procps > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4016 * > > > CVE-2023-4135 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 * > > > > > > Removed this week: 0 CVEs > > > > > > Full list: Found 110 unpatched CVEs > > > > Something doesn't add up since: > > > > https://autobuilder.yocto.io/pub/non-release/patchmetrics/ > > > > shows a fall? > > I see a fall for master, but not for dunfell. Am I missing something? Sorry, I got confused. Normally the master branch is the first in my inbox, this week it was filtered somewhere else. I was confusing the two particularly as they had similar numbers at the moment! Sorry for the noise. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185940): https://lists.openembedded.org/g/openembedded-core/message/185940 Mute This Topic: https://lists.openembedded.org/mt/100717557/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] [yocto-security] OE-core CVE metrics for dunfell on Sun 13 Aug 2023 02:00:01 AM HST
On Sun, Aug 13, 2023 at 3:02 AM Richard Purdie wrote: > > On Sun, 2023-08-13 at 02:28 -1000, Steve Sakoman wrote: > > Branch: dunfell > > > > New this week: 5 CVEs > > CVE-2023-29409 (CVSS3: 5.3 MEDIUM): go:go-native > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-29409 * > > CVE-2023-3180 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 * > > CVE-2023-3817 (CVSS3: 5.3 MEDIUM): openssl:openssl-native > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3817 * > > CVE-2023-4016 (CVSS3: 5.5 MEDIUM): procps > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4016 * > > CVE-2023-4135 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 * > > > > Removed this week: 0 CVEs > > > > Full list: Found 110 unpatched CVEs > > Something doesn't add up since: > > https://autobuilder.yocto.io/pub/non-release/patchmetrics/ > > shows a fall? I see a fall for master, but not for dunfell. Am I missing something? Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185939): https://lists.openembedded.org/g/openembedded-core/message/185939 Mute This Topic: https://lists.openembedded.org/mt/100717557/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH] openssl: Backport fix CVE-2023-2975
Signed-off-by: Ashish Sharma
---
.../openssl/openssl/CVE-2023-2975.patch | 61 +++
.../openssl/openssl_3.0.9.bb | 1 +
2 files changed, 62 insertions(+)
create mode 100644
meta/recipes-connectivity/openssl/openssl/CVE-2023-2975.patch
diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2023-2975.patch
b/meta/recipes-connectivity/openssl/openssl/CVE-2023-2975.patch
new file mode 100644
index 000..fe78e87a831
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/CVE-2023-2975.patch
@@ -0,0 +1,61 @@
+From 00e2f5eea29994d19293ec4e8c8775ba73678598 Mon Sep 17 00:00:00 2001
+From: Tomas Mraz
+Date: Tue, 4 Jul 2023 17:30:35 +0200
+Subject: [PATCH] Do not ignore empty associated data with AES-SIV mode
+
+The AES-SIV mode allows for multiple associated data items
+authenticated separately with any of these being 0 length.
+
+The provided implementation ignores such empty associated data
+which is incorrect in regards to the RFC 5297 and is also
+a security issue because such empty associated data then become
+unauthenticated if an application expects to authenticate them.
+
+Fixes CVE-2023-2975
+
+Reviewed-by: Matt Caswell
+Reviewed-by: Paul Dale
+(Merged from https://github.com/openssl/openssl/pull/21384)
+
+(cherry picked from commit c426c281cfc23ab182f7d7d7a35229e7db1494d9)
+
+Upstream-Status: Backport
[https://git.openssl.org/gitweb/?p=openssl.git;a=patch;h=00e2f5eea29994d19293ec4e8c8775ba73678598]
+CVE: CVE-2023-2975
+Signed-off-by: Ashish Sharma
+
+ .../implementations/ciphers/cipher_aes_siv.c | 18 +++---
+ 1 file changed, 11 insertions(+), 7 deletions(-)
+
+diff --git a/providers/implementations/ciphers/cipher_aes_siv.c
b/providers/implementations/ciphers/cipher_aes_siv.c
+index 45010b90db..b396c8651a 100644
+--- a/providers/implementations/ciphers/cipher_aes_siv.c
b/providers/implementations/ciphers/cipher_aes_siv.c
+@@ -120,14 +120,18 @@ static int siv_cipher(void *vctx, unsigned char *out,
size_t *outl,
+ if (!ossl_prov_is_running())
+ return 0;
+
+-if (inl == 0) {
+-*outl = 0;
+-return 1;
+-}
++/* Ignore just empty encryption/decryption call and not AAD. */
++if (out != NULL) {
++if (inl == 0) {
++if (outl != NULL)
++*outl = 0;
++return 1;
++}
+
+-if (outsize < inl) {
+-ERR_raise(ERR_LIB_PROV, PROV_R_OUTPUT_BUFFER_TOO_SMALL);
+-return 0;
++if (outsize < inl) {
++ERR_raise(ERR_LIB_PROV, PROV_R_OUTPUT_BUFFER_TOO_SMALL);
++return 0;
++}
+ }
+
+ if (ctx->hw->cipher(ctx, out, in, inl) <= 0)
+--
+2.34.1
+
diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.9.bb
b/meta/recipes-connectivity/openssl/openssl_3.0.9.bb
index 849bd7e5a69..61e81cfa09d 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.0.9.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.0.9.bb
@@ -12,6 +12,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz
\
file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
file://afalg.patch \
file://0001-Configure-do-not-tweak-mips-cflags.patch \
+ file://CVE-2023-2975.patch \
"
SRC_URI:append:class-nativesdk = " \
--
2.35.7
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185938):
https://lists.openembedded.org/g/openembedded-core/message/185938
Mute This Topic: https://lists.openembedded.org/mt/100740204/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH] curl: Backport fix CVE-2023-32001
Signed-off-by: Ashish Sharma
---
.../curl/curl/CVE-2023-32001.patch| 39 +++
meta/recipes-support/curl/curl_7.82.0.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644 meta/recipes-support/curl/curl/CVE-2023-32001.patch
diff --git a/meta/recipes-support/curl/curl/CVE-2023-32001.patch
b/meta/recipes-support/curl/curl/CVE-2023-32001.patch
new file mode 100644
index 000..7ea30737555
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2023-32001.patch
@@ -0,0 +1,39 @@
+From 0c667188e0c6cda615a036b8a2b4125f2c404dde Mon Sep 17 00:00:00 2001
+From: SaltyMilk
+Date: Mon, 10 Jul 2023 21:43:28 +0200
+Subject: [PATCH] fopen: optimize
+
+Closes #11419
+
+Upstream-Status: Backport
[https://github.com/curl/curl/commit/0c667188e0c6cda615a036b8a2b4125f2c404dde]
+CVE: CVE-2023-32001
+Signed-off-by: Ashish Sharma
+
+
+ lib/fopen.c | 12 ++--
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/lib/fopen.c b/lib/fopen.c
+index c9c9e3d6e73a2..b6e3cadddef65 100644
+--- a/lib/fopen.c
b/lib/fopen.c
+@@ -56,13 +56,13 @@ CURLcode Curl_fopen(struct Curl_easy *data, const char
*filename,
+ int fd = -1;
+ *tempname = NULL;
+
+- if(stat(filename, ) == -1 || !S_ISREG(sb.st_mode)) {
+-/* a non-regular file, fallback to direct fopen() */
+-*fh = fopen(filename, FOPEN_WRITETEXT);
+-if(*fh)
+- return CURLE_OK;
++ *fh = fopen(filename, FOPEN_WRITETEXT);
++ if(!*fh)
+ goto fail;
+- }
++ if(fstat(fileno(*fh), ) == -1 || !S_ISREG(sb.st_mode))
++return CURLE_OK;
++ fclose(*fh);
++ *fh = NULL;
+
+ result = Curl_rand_hex(data, randsuffix, sizeof(randsuffix));
+ if(result)
diff --git a/meta/recipes-support/curl/curl_7.82.0.bb
b/meta/recipes-support/curl/curl_7.82.0.bb
index 7f18ef7ee6a..af52ecad133 100644
--- a/meta/recipes-support/curl/curl_7.82.0.bb
+++ b/meta/recipes-support/curl/curl_7.82.0.bb
@@ -51,6 +51,7 @@ SRC_URI = "https://curl.se/download/${BP}.tar.xz \
file://CVE-2023-28321.patch \
file://CVE-2023-28322-1.patch \
file://CVE-2023-28322-2.patch \
+ file://CVE-2023-32001.patch \
"
SRC_URI[sha256sum] =
"0aaa12d7bd04b0966254f2703ce80dd5c38dbbd76af0297d3d690cdce58a583c"
--
2.35.7
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185937):
https://lists.openembedded.org/g/openembedded-core/message/185937
Mute This Topic: https://lists.openembedded.org/mt/100739129/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] [mickledore][PATCH] binutils: stable 2.40 branch updates
On Mon, Aug 14, 2023 at 4:51 AM Sanjana V wrote:
>
> Below commits on binutils-2.40 stable branch are updated.
>
> 391fd4d9ee5 PR30697, ppc32 mix of local-dynamic and global-dynamic TLS
> 7ad52a2357f [GOLD] powerpc DT_RELACOUNT
> 03f49a0619c PR30536, ppc64el gold linker produces unusable clang-16 binary
>
LGTM
> Signed-off-by: sanjana
> ---
> meta/recipes-devtools/binutils/binutils-2.40.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/binutils/binutils-2.40.inc
> b/meta/recipes-devtools/binutils/binutils-2.40.inc
> index fb99d93b26..33e7f4198d 100644
> --- a/meta/recipes-devtools/binutils/binutils-2.40.inc
> +++ b/meta/recipes-devtools/binutils/binutils-2.40.inc
> @@ -18,7 +18,7 @@ SRCBRANCH ?= "binutils-2_40-branch"
>
> UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
>
> -SRCREV ?= "7343182dd163d14b7e17c255515940dff67f2bbd"
> +SRCREV ?= "391fd4d9ee5d2b78244cbcd57fc405738359b70b"
> BINUTILS_GIT_URI ?=
> "git://sourceware.org/git/binutils-gdb.git;branch=${SRCBRANCH};protocol=https"
> SRC_URI = "\
> ${BINUTILS_GIT_URI} \
> --
> 2.34.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185936):
https://lists.openembedded.org/g/openembedded-core/message/185936
Mute This Topic: https://lists.openembedded.org/mt/100734909/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] [mickledore][PATCH] binutils: stable 2.40 branch updates
Regression testing is done and no regressions found. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185935): https://lists.openembedded.org/g/openembedded-core/message/185935 Mute This Topic: https://lists.openembedded.org/mt/100734909/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] qemu: Upgrade 8.0.3 -> 8.0.4
Signed-off-by: Richard Purdie
---
.../qemu/{qemu-native_8.0.3.bb => qemu-native_8.0.4.bb} | 0
meta/recipes-devtools/qemu/qemu.inc | 2 +-
meta/recipes-devtools/qemu/{qemu_8.0.3.bb => qemu_8.0.4.bb} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/qemu/{qemu-native_8.0.3.bb =>
qemu-native_8.0.4.bb} (100%)
rename meta/recipes-devtools/qemu/{qemu_8.0.3.bb => qemu_8.0.4.bb} (100%)
diff --git a/meta/recipes-devtools/qemu/qemu-native_8.0.3.bb
b/meta/recipes-devtools/qemu/qemu-native_8.0.4.bb
similarity index 100%
rename from meta/recipes-devtools/qemu/qemu-native_8.0.3.bb
rename to meta/recipes-devtools/qemu/qemu-native_8.0.4.bb
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index eaabc0e7066..ea02bf0c73d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -33,7 +33,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
-SRC_URI[sha256sum] =
"ecf4d32cbef9d397bfc8cc50e4d1e92a1b30253bf32e8ee73c7a8dcf9a232b09"
+SRC_URI[sha256sum] =
"81c817dda38af958be5bef1a6cf55b658bb2d3fb87c1e6a571de6b7b2c44516c"
SRC_URI:append:class-target = " file://cross.patch"
SRC_URI:append:class-nativesdk = " file://cross.patch"
diff --git a/meta/recipes-devtools/qemu/qemu_8.0.3.bb
b/meta/recipes-devtools/qemu/qemu_8.0.4.bb
similarity index 100%
rename from meta/recipes-devtools/qemu/qemu_8.0.3.bb
rename to meta/recipes-devtools/qemu/qemu_8.0.4.bb
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185934):
https://lists.openembedded.org/g/openembedded-core/message/185934
Mute This Topic: https://lists.openembedded.org/mt/100734979/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [mickledore][PATCH] binutils: stable 2.40 branch updates
Below commits on binutils-2.40 stable branch are updated.
391fd4d9ee5 PR30697, ppc32 mix of local-dynamic and global-dynamic TLS
7ad52a2357f [GOLD] powerpc DT_RELACOUNT
03f49a0619c PR30536, ppc64el gold linker produces unusable clang-16 binary
Signed-off-by: sanjana
---
meta/recipes-devtools/binutils/binutils-2.40.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/binutils/binutils-2.40.inc
b/meta/recipes-devtools/binutils/binutils-2.40.inc
index fb99d93b26..33e7f4198d 100644
--- a/meta/recipes-devtools/binutils/binutils-2.40.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.40.inc
@@ -18,7 +18,7 @@ SRCBRANCH ?= "binutils-2_40-branch"
UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
-SRCREV ?= "7343182dd163d14b7e17c255515940dff67f2bbd"
+SRCREV ?= "391fd4d9ee5d2b78244cbcd57fc405738359b70b"
BINUTILS_GIT_URI ?=
"git://sourceware.org/git/binutils-gdb.git;branch=${SRCBRANCH};protocol=https"
SRC_URI = "\
${BINUTILS_GIT_URI} \
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185933):
https://lists.openembedded.org/g/openembedded-core/message/185933
Mute This Topic: https://lists.openembedded.org/mt/100734909/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 v4] qemu: Add qemu-common package
On Mon, 2023-08-14 at 17:46 +0800, Yu, Mingli wrote:
> Hi Richard,
>
> On 8/14/23 17:25, Richard Purdie 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 Mon, 2023-08-14 at 17:19 +0800, Yu, Mingli wrote:
> > > Ping.
> >
> > https://lists.openembedded.org/g/openembedded-core/message/184574
> >
> > """
> > So why not just add:
> >
> > RRECOMMENDS:${PN} += "${PN}-system-all ${PN}-user-all"
> >
> > as I think we've then covered all the options we need?
> > """
> >
> > I still haven't seen an answer to this?
>
> Sorry for noise, have ever answered this question in another thread
> "[PATCH v3] qemu: Add qemu-common package".
>
> If just add RRECOMMENDS:${PN} += "${PN}-system-all ${PN}-user-all" by
> default, then how about the user who want only install
> qemu-system-aarch64-7.2.0-r0.corei7_64.rpm still install all qemu
> binaries as qemu-system-aarch64 rdepends on qemu which RRECOMMENDS
> qemu-system-all and
> qemu-user-all(https://git.openembedded.org/openembedded-core/commit/?id=893846ead7ee54d53e9076150cd655e0c8bca5db).
>
> So it's better make qemu as meta package to keep backward compatibility
> for user who install qemu can install all qemu binaries as before and
> also can meet the need for user who want just install qemu arm64
> emulation rpm such as
> qemu-system-aarch64-7.2.0-r0.corei7_64.rpm(https://patchwork.yoctoproject.org/project/oe-core/patch/20230717071114.2734859-1-mingli...@eng.windriver.com/)
>
> via adding IMAGE_INSTALL:append = " qemu-system-aarch64" into
> conf/local.conf.
Sorry, I'd missed that reply in the midst of the different emails and
it does help explain things thanks.
I don't like the amount of churn we've had in qemu packaging but this
does look like what we'll need to do to resolve the issue you've
mentioned above. I'll queue it for testing.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185932):
https://lists.openembedded.org/g/openembedded-core/message/185932
Mute This Topic: https://lists.openembedded.org/mt/100190357/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] [RFC][PATCHV2 0/4] Introduction of cargo-c class and recipe
On Mon, 2023-08-14 at 11:39 +0200, Frédéric Martinsons wrote: > > > Le lun. 14 août 2023, 10:46, Richard Purdie > a écrit : > > On Mon, 2023-08-14 at 09:30 +0200, Frédéric Martinsons wrote: > > > > > > > > > On Sun, 13 Aug 2023 at 17:05, Richard Purdie > > > wrote: > > > > On Sun, 2023-08-13 at 17:00 +0200, Frédéric Martinsons wrote: > > > > > On Sun, 13 Aug 2023 at 16:53, Richard Purdie > > > > > wrote: > > > > > > > > > > > > and a reproducibility failure: > > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3355/steps/13/logs/stdio > > > > > > > > > > > > which leads to: > > > > > > > > > > > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230813-z_b2j3ha/packages/diff-html/ > > > > > > > > > > > > > > > > > > > > > Argh, this makes me remember > > > > > of https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090 > > > > > Do you know if any of cargo based recipe is reproducible ? > > > > > Should I add EXCLUDE_FROM_WORLD in cargo-c ? > > > > > > > > At some point we're going to have to dive in and fix the > > > > reproducibility issues so I'm reluctant to take more patches > > > > with > > > > that > > > > set... > > > > > > > > > > > > > It will hardly be doable to correct the reproducibility of rust > > > packages since rust/cargo > > > itself have issues upstream. I take a look and there are lot of > > > open > > > issues > > > cargo: > > > https://github.com/rust-lang/cargo/issues?q=is%3Aissue+is%3Aopen+labe > > > l%3AA-reproducibility+ > > > rust: > > > https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label > > > %3AA-reproducibility > > > > I believe there is one problematic reference left which causes > > problems > > for core rust. Fixing that issue would be the best place to start > > and > > then we can work from there. > > > > We do already have a lot of good reproducibility pieces in the > > toolchain so not every upstream bug will apply to us. > > I'm afraid I do not see what is your point, can you elaborate please? > What is the "problematic reference left which causes problems > for core rust" you refer to? https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875 There appeared to be one reference left in the binaries we couldn't track down. If we fix that one reference, at least the main rust recipe issues *should* be fixed. > > > There was an RFC accepted back in may > > > (https://github.com/rust-lang/rfcs/pull/3127) and implementation > > > progress have a tracking issue in cargo > > > (https://github.com/rust-lang/cargo/issues/12137) and in rust > > > (https://github.com/rust-lang/rust/issues/111540). > > > > > > Don't know if it will fix our root issue > > > (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875) but I > > > don't > > > see how to workaround all of that without this upstream work. > > > > > > For cargo-c specific issues, I'll try to make things better (the > > > TMPDIR in debug symbols) but I'm wondering > > > something, reproducibility is desirable for all generated > > > artifacts > > > or is it only for target ones ? I mean, > > > the cargo-c is used in native so I'm wondering if making it > > > native > > > only would be acceptable ? > > > > That would certainly avoid this issue. It would also make on target > > testing of the functionality not possible. > > The test I added is on the final binary generated (rust-c-lib- > examble-bin), not cargo-c itself. So the target test would still be > valid. Ok, good. > I tested a release build with a custom patch that strips debuginfo > (strip="debug info" in Cargo.toml) and I do not have build path > leaking in debug symbol anymore. I'll dig this up more and see if I > can upstream that. Debug symbols should be relocated correctly if we pass the correct compiler options. We usually prefer debug symbols to be present so we can package them into the -dbg packages. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185931): https://lists.openembedded.org/g/openembedded-core/message/185931 Mute This Topic: https://lists.openembedded.org/mt/100715215/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Dilemma on changes - merge or not to merge (e.g. 6.4)
I'm becoming a little weary/wary of some of the changes that are coming in. The challenge is that once they merge, issues become the problem of a very small number of people. My current dilemma is the 6.4 kernel. People would like it, we'd really ideally use it for the next release but there are issues. I've worked through a few, at least pinning down where the issues were then resolving them with the help of others (thanks Bruce, Jon, Ross). Remaining are: * an error upon boot on preempt-rt on qemux86-64 (e.g. https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/7616/steps/36/logs/stdio) We'll probably just have to ignore it in parselogs as it has been around for a while and nobody seems interested in fixing it upstream. * some random hangs: https://autobuilder.yoctoproject.org/typhoon/#/builders/148/builds/349/steps/12/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/148/builds/354/steps/12/logs/stdio The latter are rare and intermittent, mainly taking out CI test builds. Most people aren't affected by them, find them hard to reproduce let alone fix and will ignore them. That will leave me/Bruce/PaulG holding the pieces. I know Bruce spends a ton of time debugging weird things just to get the kernel to the point we can even consider merging and nobody ever really sees or appreciates that work :(. Systemd was a similar challenge recently, multiple patches causing multiple issues with a significant impact on CI. In that case the issues weren't intermittent so resolution wasn't so bad. Rust and reproducibility was given a pass so the rest of the changes could merge for it. That just meant there was less pressure and the reproducibility issue is still there with people saying its too hard. That issue is now spreading down the chain to other recipes. The toolchain test reports have thousands of failures nobody is really looking at. Similarly the now consistent ltp controllers failures (previously the reports weren't even consistent!). I'm worried the access control patches changing the tar format are going to destablise and once merged, people will move on to other things leaving any remaining intermittent issues to me. Already we're seeing things like sstate being blamed as it is easiest to do that. I end up having to "prove" it isn't that. There are intermittent ptests on the autobuilder too. I took mdadm ptest patches on the basis there was help to fix them. We are still see a lot of failures in CI from there. The glib-networking intermittent failures continue, I know Trevor has tried to dig into those but he is alone in doing it in code which isn't easy to navigate (and I don't know how to help there). As an idea of impact, every time one of these things fails in CI, someone has triage that failure. The bug triage team has to triage the bugs too. I don't know how we fix this but we really could do with more people able to dive in and help with these intermittent issues. I'm really really apprehensive about merging some patches as I can just tell they're going to cause pain :(. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185930): https://lists.openembedded.org/g/openembedded-core/message/185930 Mute This Topic: https://lists.openembedded.org/mt/100733646/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 v4] qemu: Add qemu-common package
Hi Richard,
On 8/14/23 17:25, Richard Purdie 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 Mon, 2023-08-14 at 17:19 +0800, Yu, Mingli wrote:
Ping.
https://lists.openembedded.org/g/openembedded-core/message/184574
"""
So why not just add:
RRECOMMENDS:${PN} += "${PN}-system-all ${PN}-user-all"
as I think we've then covered all the options we need?
"""
I still haven't seen an answer to this?
Sorry for noise, have ever answered this question in another thread
"[PATCH v3] qemu: Add qemu-common package".
If just add RRECOMMENDS:${PN} += "${PN}-system-all ${PN}-user-all" by
default, then how about the user who want only install
qemu-system-aarch64-7.2.0-r0.corei7_64.rpm still install all qemu
binaries as qemu-system-aarch64 rdepends on qemu which RRECOMMENDS
qemu-system-all and
qemu-user-all(https://git.openembedded.org/openembedded-core/commit/?id=893846ead7ee54d53e9076150cd655e0c8bca5db).
So it's better make qemu as meta package to keep backward compatibility
for user who install qemu can install all qemu binaries as before and
also can meet the need for user who want just install qemu arm64
emulation rpm such as
qemu-system-aarch64-7.2.0-r0.corei7_64.rpm(https://patchwork.yoctoproject.org/project/oe-core/patch/20230717071114.2734859-1-mingli...@eng.windriver.com/)
via adding IMAGE_INSTALL:append = " qemu-system-aarch64" into
conf/local.conf.
Thanks,
I don't like the fact we've messed this packaging around multiple times
and still don't seem clear on the problem(s) we're solving.
Cheers,
Richard
Thanks,
On 7/17/23 15:11, Yu, Mingli wrote:
From: Mingli Yu
We split the qemu package [1] to add support to make user can install
one qemu arch emulation rpm to ease the concerns who care much about
the rpm size in embedded device.
But for the user who only install the qemu-*.rpm can't do anything
except they install the qemu emulation rpm like qemu-system-x86-64-*.rpm
explicitly.
So add qemu-common package to package all thing into qemu-common when
not split the package, and package only the basic into qemu-common and
other arch related to each qemu arch emulation rpm when split the package
to fix the backward compatibility.
qenu-*.rpm which is meta package rdepends on qemu-common and the available
qemu arch emulation rpm like qemu-system-x86-64-*.rpm and etc.
[1]
https://git.openembedded.org/openembedded-core/commit/?id=893846ead7ee54d53e9076150cd655e0c8bca5db
Signed-off-by: Mingli Yu
---
v3->v4: remove the added native-sdk dependency.
meta/recipes-devtools/qemu/qemu.inc | 23 ---
meta/recipes-devtools/qemu/qemu_8.0.3.bb | 2 +-
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 16581db69d..76560f454d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -225,15 +225,18 @@ PACKAGECONFIG[brlapi] = "--enable-brlapi,--disable-brlapi"
PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack,"
PACKAGECONFIG[debuginfo] = "--enable-libdw,--disable-libdw,elfutils"
-INSANE_SKIP:${PN} = "arch"
+INSANE_SKIP:${PN}-common = "arch"
FILES:${PN} += "${datadir}/icons"
# For user who want to install all arch packages
-PACKAGES =+ "${PN}-system-all ${PN}-user-all"
+PACKAGES =+ "${PN}-common"
+RDEPENDS:${PN} += "${PN}-common"
-ALLOW_EMPTY:${PN}-system-all = "1"
-ALLOW_EMPTY:${PN}-user-all = "1"
+ALLOW_EMPTY:${PN} = "1"
+FILES:${PN} = ""
+
+FILES:${PN}-common = "${bindir}/* ${includedir}/* ${libexecdir}/* ${datadir}/*
${localstatedir}"
PACKAGES_DYNAMIC += "^${PN}-user-.* ^${PN}-system-.*"
@@ -241,15 +244,13 @@ PACKAGESPLITFUNCS =+ "split_qemu_packages"
python split_qemu_packages () {
archdir = d.expand('${bindir}/')
-syspackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$',
'${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True)
-if syspackages:
-d.setVar('RDEPENDS:' + d.getVar('PN') + '-system-all', '
'.join(syspackages))
+subpackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$',
'${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True,
extra_depends='${PN}-common')
-userpackages = do_split_packages(d, archdir,
r'^qemu-((?!system|edid|ga|img|io|nbd|pr-helper|storage-daemon).*)$',
'${PN}-user-%s', 'QEMU full user emulation binaries(%s)' , prepend=True)
-if userpackages:
-d.setVar('RDEPENDS:' + d.getVar('PN') + '-user-all', '
'.join(userpackages))
+subpackages += do_split_packages(d, archdir,
r'^qemu-((?!system|edid|ga|img|io|nbd|pr-helper|storage-daemon).*)$',
'${PN}-user-%s', 'QEMU full user emulation binaries(%s)' , prepend=True,
extra_depends='${PN}-common')
+if subpackages:
+d.appendVar('RDEPENDS:' + d.getVar('PN'), ' ' + '
Re: [OE-core] [RFC][PATCHV2 0/4] Introduction of cargo-c class and recipe
Le lun. 14 août 2023, 10:46, Richard Purdie < richard.pur...@linuxfoundation.org> a écrit : > On Mon, 2023-08-14 at 09:30 +0200, Frédéric Martinsons wrote: > > > > > > On Sun, 13 Aug 2023 at 17:05, Richard Purdie > > wrote: > > > On Sun, 2023-08-13 at 17:00 +0200, Frédéric Martinsons wrote: > > > > On Sun, 13 Aug 2023 at 16:53, Richard Purdie > > > > wrote: > > > > > > > > > > and a reproducibility failure: > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3355/steps/13/logs/stdio > > > > > > > > > > which leads to: > > > > > > > > > > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230813-z_b2j3ha/packages/diff-html/ > > > > > > > > > > > > > > > > > Argh, this makes me remember > > > > of https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090 > > > > Do you know if any of cargo based recipe is reproducible ? > > > > Should I add EXCLUDE_FROM_WORLD in cargo-c ? > > > > > > At some point we're going to have to dive in and fix the > > > reproducibility issues so I'm reluctant to take more patches with > > > that > > > set... > > > > > > > > > It will hardly be doable to correct the reproducibility of rust > > packages since rust/cargo > > itself have issues upstream. I take a look and there are lot of open > > issues > > cargo: > > https://github.com/rust-lang/cargo/issues?q=is%3Aissue+is%3Aopen+labe > > l%3AA-reproducibility+ > > rust: > > https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label > > %3AA-reproducibility > > I believe there is one problematic reference left which causes problems > for core rust. Fixing that issue would be the best place to start and > then we can work from there. > > We do already have a lot of good reproducibility pieces in the > toolchain so not every upstream bug will apply to us. > I'm afraid I do not see what is your point, can you elaborate please? What is the "problematic reference left which causes problems for core rust" you refer to? > > There was an RFC accepted back in may > > (https://github.com/rust-lang/rfcs/pull/3127) and implementation > > progress have a tracking issue in cargo > > (https://github.com/rust-lang/cargo/issues/12137) and in rust > > (https://github.com/rust-lang/rust/issues/111540). > > > > Don't know if it will fix our root issue > > (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875) but I don't > > see how to workaround all of that without this upstream work. > > > > For cargo-c specific issues, I'll try to make things better (the > > TMPDIR in debug symbols) but I'm wondering > > something, reproducibility is desirable for all generated artifacts > > or is it only for target ones ? I mean, > > the cargo-c is used in native so I'm wondering if making it native > > only would be acceptable ? > > That would certainly avoid this issue. It would also make on target > testing of the functionality not possible. > The test I added is on the final binary generated (rust-c-lib-examble-bin), not cargo-c itself. So the target test would still be valid. I tested a release build with a custom patch that strips debuginfo (strip="debug info" in Cargo.toml) and I do not have build path leaking in debug symbol anymore. I'll dig this up more and see if I can upstream that. But the reproducible issue remain despite that. > Cheers, > > Richard > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185928): https://lists.openembedded.org/g/openembedded-core/message/185928 Mute This Topic: https://lists.openembedded.org/mt/100715215/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 v4] qemu: Add qemu-common package
On Mon, 2023-08-14 at 17:19 +0800, Yu, Mingli wrote:
> Ping.
https://lists.openembedded.org/g/openembedded-core/message/184574
"""
So why not just add:
RRECOMMENDS:${PN} += "${PN}-system-all ${PN}-user-all"
as I think we've then covered all the options we need?
"""
I still haven't seen an answer to this?
I don't like the fact we've messed this packaging around multiple times
and still don't seem clear on the problem(s) we're solving.
Cheers,
Richard
>
> Thanks,
>
> On 7/17/23 15:11, Yu, Mingli wrote:
> > From: Mingli Yu
> >
> > We split the qemu package [1] to add support to make user can install
> > one qemu arch emulation rpm to ease the concerns who care much about
> > the rpm size in embedded device.
> >
> > But for the user who only install the qemu-*.rpm can't do anything
> > except they install the qemu emulation rpm like qemu-system-x86-64-*.rpm
> > explicitly.
> >
> > So add qemu-common package to package all thing into qemu-common when
> > not split the package, and package only the basic into qemu-common and
> > other arch related to each qemu arch emulation rpm when split the package
> > to fix the backward compatibility.
> >
> > qenu-*.rpm which is meta package rdepends on qemu-common and the available
> > qemu arch emulation rpm like qemu-system-x86-64-*.rpm and etc.
> >
> > [1]
> > https://git.openembedded.org/openembedded-core/commit/?id=893846ead7ee54d53e9076150cd655e0c8bca5db
> >
> > Signed-off-by: Mingli Yu
> > ---
> >
> > v3->v4: remove the added native-sdk dependency.
> >
> > meta/recipes-devtools/qemu/qemu.inc | 23 ---
> > meta/recipes-devtools/qemu/qemu_8.0.3.bb | 2 +-
> > 2 files changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/qemu/qemu.inc
> > b/meta/recipes-devtools/qemu/qemu.inc
> > index 16581db69d..76560f454d 100644
> > --- a/meta/recipes-devtools/qemu/qemu.inc
> > +++ b/meta/recipes-devtools/qemu/qemu.inc
> > @@ -225,15 +225,18 @@ PACKAGECONFIG[brlapi] =
> > "--enable-brlapi,--disable-brlapi"
> > PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack,"
> > PACKAGECONFIG[debuginfo] = "--enable-libdw,--disable-libdw,elfutils"
> >
> > -INSANE_SKIP:${PN} = "arch"
> > +INSANE_SKIP:${PN}-common = "arch"
> >
> > FILES:${PN} += "${datadir}/icons"
> >
> > # For user who want to install all arch packages
> > -PACKAGES =+ "${PN}-system-all ${PN}-user-all"
> > +PACKAGES =+ "${PN}-common"
> > +RDEPENDS:${PN} += "${PN}-common"
> >
> > -ALLOW_EMPTY:${PN}-system-all = "1"
> > -ALLOW_EMPTY:${PN}-user-all = "1"
> > +ALLOW_EMPTY:${PN} = "1"
> > +FILES:${PN} = ""
> > +
> > +FILES:${PN}-common = "${bindir}/* ${includedir}/* ${libexecdir}/*
> > ${datadir}/* ${localstatedir}"
> >
> > PACKAGES_DYNAMIC += "^${PN}-user-.* ^${PN}-system-.*"
> >
> > @@ -241,15 +244,13 @@ PACKAGESPLITFUNCS =+ "split_qemu_packages"
> >
> > python split_qemu_packages () {
> > archdir = d.expand('${bindir}/')
> > -syspackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$',
> > '${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True)
> > -if syspackages:
> > -d.setVar('RDEPENDS:' + d.getVar('PN') + '-system-all', '
> > '.join(syspackages))
> > +subpackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$',
> > '${PN}-system-%s', 'QEMU full system emulation binaries(%s)' ,
> > prepend=True, extra_depends='${PN}-common')
> >
> > -userpackages = do_split_packages(d, archdir,
> > r'^qemu-((?!system|edid|ga|img|io|nbd|pr-helper|storage-daemon).*)$',
> > '${PN}-user-%s', 'QEMU full user emulation binaries(%s)' , prepend=True)
> > -if userpackages:
> > -d.setVar('RDEPENDS:' + d.getVar('PN') + '-user-all', '
> > '.join(userpackages))
> > +subpackages += do_split_packages(d, archdir,
> > r'^qemu-((?!system|edid|ga|img|io|nbd|pr-helper|storage-daemon).*)$',
> > '${PN}-user-%s', 'QEMU full user emulation binaries(%s)' , prepend=True,
> > extra_depends='${PN}-common')
> > +if subpackages:
> > +d.appendVar('RDEPENDS:' + d.getVar('PN'), ' ' + '
> > '.join(subpackages))
> > mipspackage = d.getVar('PN') + "-user-mips"
> > -if mipspackage in ' '.join(userpackages):
> > +if mipspackage in ' '.join(subpackages):
> > d.appendVar('RDEPENDS:' + mipspackage, ' ' + d.getVar("MLPREFIX")
> > + 'bash')
> > }
> >
> > diff --git a/meta/recipes-devtools/qemu/qemu_8.0.3.bb
> > b/meta/recipes-devtools/qemu/qemu_8.0.3.bb
> > index 42e133967e..5d3c47c3b0 100644
> > --- a/meta/recipes-devtools/qemu/qemu_8.0.3.bb
> > +++ b/meta/recipes-devtools/qemu/qemu_8.0.3.bb
> > @@ -8,7 +8,7 @@ DEPENDS:append:libc-musl = " libucontext"
> >
> > CFLAGS += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '',
> > '-DEGL_NO_X11=1', d)}"
> >
> > -RDEPENDS:${PN}:class-target += "bash"
> > +RDEPENDS:${PN}-common:class-target += "bash"
> >
> > EXTRA_OECONF:append:class-target = "
> >
Re: [OE-core] [PATCH v4] qemu: Add qemu-common package
Ping.
Thanks,
On 7/17/23 15:11, Yu, Mingli wrote:
From: Mingli Yu
We split the qemu package [1] to add support to make user can install
one qemu arch emulation rpm to ease the concerns who care much about
the rpm size in embedded device.
But for the user who only install the qemu-*.rpm can't do anything
except they install the qemu emulation rpm like qemu-system-x86-64-*.rpm
explicitly.
So add qemu-common package to package all thing into qemu-common when
not split the package, and package only the basic into qemu-common and
other arch related to each qemu arch emulation rpm when split the package
to fix the backward compatibility.
qenu-*.rpm which is meta package rdepends on qemu-common and the available
qemu arch emulation rpm like qemu-system-x86-64-*.rpm and etc.
[1]
https://git.openembedded.org/openembedded-core/commit/?id=893846ead7ee54d53e9076150cd655e0c8bca5db
Signed-off-by: Mingli Yu
---
v3->v4: remove the added native-sdk dependency.
meta/recipes-devtools/qemu/qemu.inc | 23 ---
meta/recipes-devtools/qemu/qemu_8.0.3.bb | 2 +-
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 16581db69d..76560f454d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -225,15 +225,18 @@ PACKAGECONFIG[brlapi] = "--enable-brlapi,--disable-brlapi"
PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack,"
PACKAGECONFIG[debuginfo] = "--enable-libdw,--disable-libdw,elfutils"
-INSANE_SKIP:${PN} = "arch"
+INSANE_SKIP:${PN}-common = "arch"
FILES:${PN} += "${datadir}/icons"
# For user who want to install all arch packages
-PACKAGES =+ "${PN}-system-all ${PN}-user-all"
+PACKAGES =+ "${PN}-common"
+RDEPENDS:${PN} += "${PN}-common"
-ALLOW_EMPTY:${PN}-system-all = "1"
-ALLOW_EMPTY:${PN}-user-all = "1"
+ALLOW_EMPTY:${PN} = "1"
+FILES:${PN} = ""
+
+FILES:${PN}-common = "${bindir}/* ${includedir}/* ${libexecdir}/* ${datadir}/*
${localstatedir}"
PACKAGES_DYNAMIC += "^${PN}-user-.* ^${PN}-system-.*"
@@ -241,15 +244,13 @@ PACKAGESPLITFUNCS =+ "split_qemu_packages"
python split_qemu_packages () {
archdir = d.expand('${bindir}/')
-syspackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$',
'${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True)
-if syspackages:
-d.setVar('RDEPENDS:' + d.getVar('PN') + '-system-all', '
'.join(syspackages))
+subpackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$',
'${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True,
extra_depends='${PN}-common')
-userpackages = do_split_packages(d, archdir, r'^qemu-((?!system|edid|ga|img|io|nbd|pr-helper|storage-daemon).*)$', '${PN}-user-%s', 'QEMU full user emulation binaries(%s)' , prepend=True)
-if userpackages:
-d.setVar('RDEPENDS:' + d.getVar('PN') + '-user-all', '
'.join(userpackages))
+subpackages += do_split_packages(d, archdir,
r'^qemu-((?!system|edid|ga|img|io|nbd|pr-helper|storage-daemon).*)$',
'${PN}-user-%s', 'QEMU full user emulation binaries(%s)' , prepend=True,
extra_depends='${PN}-common')
+if subpackages:
+d.appendVar('RDEPENDS:' + d.getVar('PN'), ' ' + ' '.join(subpackages))
mipspackage = d.getVar('PN') + "-user-mips"
-if mipspackage in ' '.join(userpackages):
+if mipspackage in ' '.join(subpackages):
d.appendVar('RDEPENDS:' + mipspackage, ' ' + d.getVar("MLPREFIX") +
'bash')
}
diff --git a/meta/recipes-devtools/qemu/qemu_8.0.3.bb b/meta/recipes-devtools/qemu/qemu_8.0.3.bb
index 42e133967e..5d3c47c3b0 100644
--- a/meta/recipes-devtools/qemu/qemu_8.0.3.bb
+++ b/meta/recipes-devtools/qemu/qemu_8.0.3.bb
@@ -8,7 +8,7 @@ DEPENDS:append:libc-musl = " libucontext"
CFLAGS += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', '-DEGL_NO_X11=1', d)}"
-RDEPENDS:${PN}:class-target += "bash"
+RDEPENDS:${PN}-common:class-target += "bash"
EXTRA_OECONF:append:class-target = " --target-list=${@get_qemu_target_list(d)}"
EXTRA_OECONF:append:class-target:mipsarcho32 =
"${@bb.utils.contains('BBEXTENDCURR', 'multilib', ' --disable-capstone', '',
d)}"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185926):
https://lists.openembedded.org/g/openembedded-core/message/185926
Mute This Topic: https://lists.openembedded.org/mt/100190357/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] [RFC][PATCHV2 0/4] Introduction of cargo-c class and recipe
On Mon, 2023-08-14 at 09:30 +0200, Frédéric Martinsons wrote: > > > On Sun, 13 Aug 2023 at 17:05, Richard Purdie > wrote: > > On Sun, 2023-08-13 at 17:00 +0200, Frédéric Martinsons wrote: > > > On Sun, 13 Aug 2023 at 16:53, Richard Purdie > > > wrote: > > > > > > > > and a reproducibility failure: > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3355/steps/13/logs/stdio > > > > > > > > which leads to: > > > > > > > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230813-z_b2j3ha/packages/diff-html/ > > > > > > > > > > > > > Argh, this makes me remember > > > of https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090 > > > Do you know if any of cargo based recipe is reproducible ? > > > Should I add EXCLUDE_FROM_WORLD in cargo-c ? > > > > At some point we're going to have to dive in and fix the > > reproducibility issues so I'm reluctant to take more patches with > > that > > set... > > > > > It will hardly be doable to correct the reproducibility of rust > packages since rust/cargo > itself have issues upstream. I take a look and there are lot of open > issues > cargo: > https://github.com/rust-lang/cargo/issues?q=is%3Aissue+is%3Aopen+labe > l%3AA-reproducibility+ > rust: > https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label > %3AA-reproducibility I believe there is one problematic reference left which causes problems for core rust. Fixing that issue would be the best place to start and then we can work from there. We do already have a lot of good reproducibility pieces in the toolchain so not every upstream bug will apply to us. > There was an RFC accepted back in may > (https://github.com/rust-lang/rfcs/pull/3127) and implementation > progress have a tracking issue in cargo > (https://github.com/rust-lang/cargo/issues/12137) and in rust > (https://github.com/rust-lang/rust/issues/111540). > > Don't know if it will fix our root issue > (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875) but I don't > see how to workaround all of that without this upstream work. > > For cargo-c specific issues, I'll try to make things better (the > TMPDIR in debug symbols) but I'm wondering > something, reproducibility is desirable for all generated artifacts > or is it only for target ones ? I mean, > the cargo-c is used in native so I'm wondering if making it native > only would be acceptable ? That would certainly avoid this issue. It would also make on target testing of the functionality not possible. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185925): https://lists.openembedded.org/g/openembedded-core/message/185925 Mute This Topic: https://lists.openembedded.org/mt/100715215/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe-core][kirkstone][PATCH 1/1] qemu: fix CVE-2023-3180
A flaw was found in the QEMU virtual crypto device while handling data
encryption/decryption requests in virtio_crypto_handle_sym_req.
There is no check for the value of `src_len` and `dst_len` in
virtio_crypto_sym_op_helper, potentially leading to a heap buffer
overflow when the two values differ.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-3180
Upstream patches:
https://gitlab.com/qemu-project/qemu/-/commit/49f1e02bac166821c712534aaa775f50e1afe17f
Signed-off-by: Archana Polampalli
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2023-3180.patch | 49 +++
2 files changed, 50 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-3180.patch
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 3347a99e19..d77c376bb6 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -99,6 +99,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2023-2861.patch \
file://CVE-2020-14394.patch \
file://CVE-2023-3354.patch \
+ file://CVE-2023-3180.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2023-3180.patch
b/meta/recipes-devtools/qemu/qemu/CVE-2023-3180.patch
new file mode 100644
index 00..5ec7dd0aa0
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2023-3180.patch
@@ -0,0 +1,49 @@
+From 49f1e02bac166821c712534aaa775f50e1afe17f Mon Sep 17 00:00:00 2001
+From: zhenwei pi
+Date: Thu, 3 Aug 2023 10:43:13 +0800
+Subject: [PATCH] virtio-crypto: verify src buffer length for sym request
+
+For symmetric algorithms, the length of ciphertext must be as same
+as the plaintext.
+The missing verification of the src_len and the dst_len in
+virtio_crypto_sym_op_helper() may lead buffer overflow/divulged.
+
+This patch is originally written by Yiming Tao for QEMU-SECURITY,
+resend it(a few changes of error message) in qemu-devel.
+
+Fixes: CVE-2023-3180
+Fixes: 04b9b37edda("virtio-crypto: add data queue processing handler")
+Cc: Gonglei
+Cc: Mauro Matteo Cascella
+Cc: Yiming Tao
+Signed-off-by: zhenwei pi
+Message-Id: <20230803024314.29962-2-pizhen...@bytedance.com>
+Reviewed-by: Michael S. Tsirkin
+Signed-off-by: Michael S. Tsirkin
+(cherry picked from commit 9d38a8434721a6479fe03fb5afb150ca793d3980)
+Signed-off-by: Michael Tokarev
+
+Upstream-Status: Backport
[https://gitlab.com/qemu-project/qemu/-/commit/49f1e02bac166821c712534aaa775f50e1afe17f]
+CVE: CVE-2023-3180
+---
+ hw/virtio/virtio-crypto.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
+index a1d122b9aa..ccaa704530 100644
+--- a/hw/virtio/virtio-crypto.c
b/hw/virtio/virtio-crypto.c
+@@ -635,6 +635,11 @@ virtio_crypto_sym_op_helper(VirtIODevice *vdev,
+ return NULL;
+ }
+
++if (unlikely(src_len != dst_len)) {
++virtio_error(vdev, "sym request src len is different from dst len");
++return NULL;
++}
++
+ max_len = (uint64_t)iv_len + aad_len + src_len + dst_len +
hash_result_len;
+ if (unlikely(max_len > vcrypto->conf.max_size)) {
+ virtio_error(vdev, "virtio-crypto too big length");
+--
+2.40.0
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185924):
https://lists.openembedded.org/g/openembedded-core/message/185924
Mute This Topic: https://lists.openembedded.org/mt/100732602/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] [RFC][PATCHV2 0/4] Introduction of cargo-c class and recipe
On Sun, 13 Aug 2023 at 17:05, Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Sun, 2023-08-13 at 17:00 +0200, Frédéric Martinsons wrote: > > On Sun, 13 Aug 2023 at 16:53, Richard Purdie > > wrote: > > > > > > and a reproducibility failure: > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3355/steps/13/logs/stdio > > > > > > which leads to: > > > > > > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230813-z_b2j3ha/packages/diff-html/ > > > > > > > > > Argh, this makes me remember > > of https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090 > > Do you know if any of cargo based recipe is reproducible ? > > Should I add EXCLUDE_FROM_WORLD in cargo-c ? > > At some point we're going to have to dive in and fix the > reproducibility issues so I'm reluctant to take more patches with that > set... It will hardly be doable to correct the reproducibility of rust packages since rust/cargo itself have issues upstream. I take a look and there are lot of open issues cargo: https://github.com/rust-lang/cargo/issues?q=is%3Aissue+is%3Aopen+label%3AA-reproducibility+ rust: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AA-reproducibility There was an RFC accepted back in may ( https://github.com/rust-lang/rfcs/pull/3127) and implementation progress have a tracking issue in cargo ( https://github.com/rust-lang/cargo/issues/12137) and in rust (https://github.com/rust-lang/rust/issues/111540). Don't know if it will fix our root issue ( https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875) but I don't see how to workaround all of that without this upstream work. For cargo-c specific issues, I'll try to make things better (the TMPDIR in debug symbols) but I'm wondering something, reproducibility is desirable for all generated artifacts or is it only for target ones ? I mean, the cargo-c is used in native so I'm wondering if making it native only would be acceptable ? > > Cheers, > > Richard > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185923): https://lists.openembedded.org/g/openembedded-core/message/185923 Mute This Topic: https://lists.openembedded.org/mt/100715215/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
