* [OE-core][mickledore 1/5] grub2: fix CVE-2023-4692
2023-10-31 15:35 [OE-core][mickledore 0/5] Patch review Steve Sakoman
@ 2023-10-31 15:35 ` Steve Sakoman
2023-10-31 15:35 ` [OE-core][mickledore 2/5] grub2: fix CVE-2023-4693 Steve Sakoman
` (4 subsequent siblings)
5 siblings, 0 replies; 8+ messages in thread
From: Steve Sakoman @ 2023-10-31 15:35 UTC (permalink / raw)
To: openembedded-core
From: Xiangyu Chen <xiangyu.chen@windriver.com>
Crafted file system images can cause heap-based buffer overflow and may
allow arbitrary code execution and secure boot bypass
Reference:
https://security-tracker.debian.org/tracker/CVE-2023-4692
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
.../grub/files/CVE-2023-4692.patch | 98 +++++++++++++++++++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 99 insertions(+)
create mode 100644 meta/recipes-bsp/grub/files/CVE-2023-4692.patch
diff --git a/meta/recipes-bsp/grub/files/CVE-2023-4692.patch b/meta/recipes-bsp/grub/files/CVE-2023-4692.patch
new file mode 100644
index 0000000000..305fcc93d8
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/CVE-2023-4692.patch
@@ -0,0 +1,98 @@
+From 43651027d24e62a7a463254165e1e46e42aecdea Mon Sep 17 00:00:00 2001
+From: Maxim Suhanov <dfirblog@gmail.com>
+Date: Mon, 28 Aug 2023 16:31:57 +0300
+Subject: [PATCH] fs/ntfs: Fix an OOB write when parsing the $ATTRIBUTE_LIST attribute
+ for the $MFT file
+
+When parsing an extremely fragmented $MFT file, i.e., the file described
+using the $ATTRIBUTE_LIST attribute, current NTFS code will reuse a buffer
+containing bytes read from the underlying drive to store sector numbers,
+which are consumed later to read data from these sectors into another buffer.
+
+These sectors numbers, two 32-bit integers, are always stored at predefined
+offsets, 0x10 and 0x14, relative to first byte of the selected entry within
+the $ATTRIBUTE_LIST attribute. Usually, this won't cause any problem.
+
+However, when parsing a specially-crafted file system image, this may cause
+the NTFS code to write these integers beyond the buffer boundary, likely
+causing the GRUB memory allocator to misbehave or fail. These integers contain
+values which are controlled by on-disk structures of the NTFS file system.
+
+Such modification and resulting misbehavior may touch a memory range not
+assigned to the GRUB and owned by firmware or another EFI application/driver.
+
+This fix introduces checks to ensure that these sector numbers are never
+written beyond the boundary.
+
+Fixes: CVE-2023-4692
+
+Upstream-Status: Backport from
+[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=43651027d24e62a7a463254165e1e46e42aecdea]
+CVE: CVE-2023-4692
+
+Reported-by: Maxim Suhanov <dfirblog@gmail.com>
+Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
+---
+ grub-core/fs/ntfs.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
+index bbdbe24..c3c4db1 100644
+--- a/grub-core/fs/ntfs.c
++++ b/grub-core/fs/ntfs.c
+@@ -184,7 +184,7 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
+ }
+ if (at->attr_end)
+ {
+- grub_uint8_t *pa;
++ grub_uint8_t *pa, *pa_end;
+
+ at->emft_buf = grub_malloc (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR);
+ if (at->emft_buf == NULL)
+@@ -209,11 +209,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
+ }
+ at->attr_nxt = at->edat_buf;
+ at->attr_end = at->edat_buf + u32at (pa, 0x30);
++ pa_end = at->edat_buf + n;
+ }
+ else
+ {
+ at->attr_nxt = at->attr_end + u16at (pa, 0x14);
+ at->attr_end = at->attr_end + u32at (pa, 4);
++ pa_end = at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR);
+ }
+ at->flags |= GRUB_NTFS_AF_ALST;
+ while (at->attr_nxt < at->attr_end)
+@@ -230,6 +232,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
+ at->flags |= GRUB_NTFS_AF_GPOS;
+ at->attr_cur = at->attr_nxt;
+ pa = at->attr_cur;
++
++ if ((pa >= pa_end) || (pa_end - pa < 0x18))
++ {
++ grub_error (GRUB_ERR_BAD_FS, "can\'t parse attribute list");
++ return NULL;
++ }
++
+ grub_set_unaligned32 ((char *) pa + 0x10,
+ grub_cpu_to_le32 (at->mft->data->mft_start));
+ grub_set_unaligned32 ((char *) pa + 0x14,
+@@ -240,6 +249,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
+ {
+ if (*pa != attr)
+ break;
++
++ if ((pa >= pa_end) || (pa_end - pa < 0x18))
++ {
++ grub_error (GRUB_ERR_BAD_FS, "can\'t parse attribute list");
++ return NULL;
++ }
++
+ if (read_attr
+ (at, pa + 0x10,
+ u32at (pa, 0x10) * (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR),
+--
+cgit v1.1
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 58b215d79c..ac73a0b940 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -42,6 +42,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://CVE-2022-3775.patch \
file://0001-risc-v-Handle-R_RISCV_CALL_PLT-reloc.patch \
file://0001-fs-ext2-Ignore-checksum-seed-incompat-feature.patch \
+ file://CVE-2023-4692.patch \
"
SRC_URI[sha256sum] = "23b64b4c741569f9426ed2e3d0e6780796fca081bee4c99f62aa3f53ae803f5f"
--
2.34.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* [OE-core][mickledore 2/5] grub2: fix CVE-2023-4693
2023-10-31 15:35 [OE-core][mickledore 0/5] Patch review Steve Sakoman
2023-10-31 15:35 ` [OE-core][mickledore 1/5] grub2: fix CVE-2023-4692 Steve Sakoman
@ 2023-10-31 15:35 ` Steve Sakoman
2023-10-31 15:35 ` [OE-core][mickledore 3/5] shadow: Fix CVE-2023-4641 Steve Sakoman
` (3 subsequent siblings)
5 siblings, 0 replies; 8+ messages in thread
From: Steve Sakoman @ 2023-10-31 15:35 UTC (permalink / raw)
To: openembedded-core
From: Xiangyu Chen <xiangyu.chen@windriver.com>
There an out-of-bounds read at fs/ntfs.c, a physically present attacker
may leverage that by presenting a specially crafted NTFS file system
image to read arbitrary memory locations. A successful attack may allow
sensitive data cached in memory or EFI variables values to be leaked
presenting a high Confidentiality risk.
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
.../grub/files/CVE-2023-4693.patch | 63 +++++++++++++++++++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 64 insertions(+)
create mode 100644 meta/recipes-bsp/grub/files/CVE-2023-4693.patch
diff --git a/meta/recipes-bsp/grub/files/CVE-2023-4693.patch b/meta/recipes-bsp/grub/files/CVE-2023-4693.patch
new file mode 100644
index 0000000000..544226a9aa
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/CVE-2023-4693.patch
@@ -0,0 +1,63 @@
+From 0ed2458cc4eff6d9a9199527e2a0b6d445802f94 Mon Sep 17 00:00:00 2001
+From: Maxim Suhanov <dfirblog@gmail.com>
+Date: Mon, 28 Aug 2023 16:32:33 +0300
+Subject: fs/ntfs: Fix an OOB read when reading data from the resident $DATA
+ attribute
+
+When reading a file containing resident data, i.e., the file data is stored in
+the $DATA attribute within the NTFS file record, not in external clusters,
+there are no checks that this resident data actually fits the corresponding
+file record segment.
+
+When parsing a specially-crafted file system image, the current NTFS code will
+read the file data from an arbitrary, attacker-chosen memory offset and of
+arbitrary, attacker-chosen length.
+
+This allows an attacker to display arbitrary chunks of memory, which could
+contain sensitive information like password hashes or even plain-text,
+obfuscated passwords from BS EFI variables.
+
+This fix implements a check to ensure that resident data is read from the
+corresponding file record segment only.
+
+Fixes: CVE-2023-4693
+
+Upstream-Status: Backport from
+[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0ed2458cc4eff6d9a9199527e2a0b6d445802f94]
+CVE: CVE-2023-4693
+
+Reported-by: Maxim Suhanov <dfirblog@gmail.com>
+Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
+---
+ grub-core/fs/ntfs.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
+index c3c4db1..a68e173 100644
+--- a/grub-core/fs/ntfs.c
++++ b/grub-core/fs/ntfs.c
+@@ -401,7 +401,18 @@ read_data (struct grub_ntfs_attr *at, grub_uint8_t *pa, grub_uint8_t *dest,
+ {
+ if (ofs + len > u32at (pa, 0x10))
+ return grub_error (GRUB_ERR_BAD_FS, "read out of range");
+- grub_memcpy (dest, pa + u32at (pa, 0x14) + ofs, len);
++
++ if (u32at (pa, 0x10) > (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR))
++ return grub_error (GRUB_ERR_BAD_FS, "resident attribute too large");
++
++ if (pa >= at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR))
++ return grub_error (GRUB_ERR_BAD_FS, "resident attribute out of range");
++
++ if (u16at (pa, 0x14) + u32at (pa, 0x10) >
++ (grub_addr_t) at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR) - (grub_addr_t) pa)
++ return grub_error (GRUB_ERR_BAD_FS, "resident attribute out of range");
++
++ grub_memcpy (dest, pa + u16at (pa, 0x14) + ofs, len);
+ return 0;
+ }
+
+--
+cgit v1.1
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index ac73a0b940..fa949fc081 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -43,6 +43,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0001-risc-v-Handle-R_RISCV_CALL_PLT-reloc.patch \
file://0001-fs-ext2-Ignore-checksum-seed-incompat-feature.patch \
file://CVE-2023-4692.patch \
+ file://CVE-2023-4693.patch \
"
SRC_URI[sha256sum] = "23b64b4c741569f9426ed2e3d0e6780796fca081bee4c99f62aa3f53ae803f5f"
--
2.34.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* [OE-core][mickledore 3/5] shadow: Fix CVE-2023-4641
2023-10-31 15:35 [OE-core][mickledore 0/5] Patch review Steve Sakoman
2023-10-31 15:35 ` [OE-core][mickledore 1/5] grub2: fix CVE-2023-4692 Steve Sakoman
2023-10-31 15:35 ` [OE-core][mickledore 2/5] grub2: fix CVE-2023-4693 Steve Sakoman
@ 2023-10-31 15:35 ` Steve Sakoman
2023-10-31 15:35 ` [OE-core][mickledore 4/5] openssl: Upgrade 3.1.3 -> 3.1.4 Steve Sakoman
` (2 subsequent siblings)
5 siblings, 0 replies; 8+ messages in thread
From: Steve Sakoman @ 2023-10-31 15:35 UTC (permalink / raw)
To: openembedded-core
From: Xiangyu Chen <xiangyu.chen@windriver.com>
shadow-utils: possible password leak during passwd(1) change
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
.../shadow/files/CVE-2023-4641.patch | 147 ++++++++++++++++++
meta/recipes-extended/shadow/shadow.inc | 1 +
2 files changed, 148 insertions(+)
create mode 100644 meta/recipes-extended/shadow/files/CVE-2023-4641.patch
diff --git a/meta/recipes-extended/shadow/files/CVE-2023-4641.patch b/meta/recipes-extended/shadow/files/CVE-2023-4641.patch
new file mode 100644
index 0000000000..1fabfe928e
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/CVE-2023-4641.patch
@@ -0,0 +1,147 @@
+From 25dbe2ce166a13322b7536ff2f738786ea2e61e7 Mon Sep 17 00:00:00 2001
+From: Alejandro Colomar <alx@kernel.org>
+Date: Sat, 10 Jun 2023 16:20:05 +0200
+Subject: [PATCH] gpasswd(1): Fix password leak
+
+How to trigger this password leak?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When gpasswd(1) asks for the new password, it asks twice (as is usual
+for confirming the new password). Each of those 2 password prompts
+uses agetpass() to get the password. If the second agetpass() fails,
+the first password, which has been copied into the 'static' buffer
+'pass' via STRFCPY(), wasn't being zeroed.
+
+agetpass() is defined in <./libmisc/agetpass.c> (around line 91), and
+can fail for any of the following reasons:
+
+- malloc(3) or readpassphrase(3) failure.
+
+ These are going to be difficult to trigger. Maybe getting the system
+ to the limits of memory utilization at that exact point, so that the
+ next malloc(3) gets ENOMEM, and possibly even the OOM is triggered.
+ About readpassphrase(3), ENFILE and EINTR seem the only plausible
+ ones, and EINTR probably requires privilege or being the same user;
+ but I wouldn't discard ENFILE so easily, if a process starts opening
+ files.
+
+- The password is longer than PASS_MAX.
+
+ The is plausible with physical access. However, at that point, a
+ keylogger will be a much simpler attack.
+
+And, the attacker must be able to know when the second password is being
+introduced, which is not going to be easy.
+
+How to read the password after the leak?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Provoking the leak yourself at the right point by entering a very long
+password is easy, and inspecting the process stack at that point should
+be doable. Try to find some consistent patterns.
+
+Then, search for those patterns in free memory, right after the victim
+leaks their password.
+
+Once you get the leak, a program should read all the free memory
+searching for patterns that gpasswd(1) leaves nearby the leaked
+password.
+
+On 6/10/23 03:14, Seth Arnold wrote:
+> An attacker process wouldn't be able to use malloc(3) for this task.
+> There's a handful of tools available for userspace to allocate memory:
+>
+> - brk / sbrk
+> - mmap MAP_ANONYMOUS
+> - mmap /dev/zero
+> - mmap some other file
+> - shm_open
+> - shmget
+>
+> Most of these return only pages of zeros to a process. Using mmap of an
+> existing file, you can get some of the contents of the file demand-loaded
+> into the memory space on the first use.
+>
+> The MAP_UNINITIALIZED flag only works if the kernel was compiled with
+> CONFIG_MMAP_ALLOW_UNINITIALIZED. This is rare.
+>
+> malloc(3) doesn't zero memory, to our collective frustration, but all the
+> garbage in the allocations is from previous allocations in the current
+> process. It isn't leftover from other processes.
+>
+> The avenues available for reading the memory:
+> - /dev/mem and /dev/kmem (requires root, not available with Secure Boot)
+> - /proc/pid/mem (requires ptrace privileges, mediated by YAMA)
+> - ptrace (requires ptrace privileges, mediated by YAMA)
+> - causing memory to be swapped to disk, and then inspecting the swap
+>
+> These all require a certain amount of privileges.
+
+How to fix it?
+~~~~~~~~~~~~~~
+
+memzero(), which internally calls explicit_bzero(3), or whatever
+alternative the system provides with a slightly different name, will
+make sure that the buffer is zeroed in memory, and optimizations are not
+allowed to impede this zeroing.
+
+This is not really 100% effective, since compilers may place copies of
+the string somewhere hidden in the stack. Those copies won't get zeroed
+by explicit_bzero(3). However, that's arguably a compiler bug, since
+compilers should make everything possible to avoid optimizing strings
+that are later passed to explicit_bzero(3). But we all know that
+sometimes it's impossible to have perfect knowledge in the compiler, so
+this is plausible. Nevertheless, there's nothing we can do against such
+issues, except minimizing the time such passwords are stored in plain
+text.
+
+Security concerns
+~~~~~~~~~~~~~~~~~
+
+We believe this isn't easy to exploit. Nevertheless, and since the fix
+is trivial, this fix should probably be applied soon, and backported to
+all supported distributions, to prevent someone else having more
+imagination than us to find a way.
+
+Affected versions
+~~~~~~~~~~~~~~~~~
+
+All. Bug introduced in shadow 19990709. That's the second commit in
+the git history.
+
+Fixes: 45c6603cc86c ("[svn-upgrade] Integrating new upstream version, shadow (19990709)")
+
+CVE: CVE-2023-4641
+Upstream-Status: Backport [https://github.com/shadow-maint/shadow/commit/65c88a43a23c2391dcc90c0abda3e839e9c57904]
+
+Reported-by: Alejandro Colomar <alx@kernel.org>
+Cc: Serge Hallyn <serge@hallyn.com>
+Cc: Iker Pedrosa <ipedrosa@redhat.com>
+Cc: Seth Arnold <seth.arnold@canonical.com>
+Cc: Christian Brauner <christian@brauner.io>
+Cc: Balint Reczey <rbalint@debian.org>
+Cc: Sam James <sam@gentoo.org>
+Cc: David Runge <dvzrv@archlinux.org>
+Cc: Andreas Jaeger <aj@suse.de>
+Cc: <~hallyn/shadow@lists.sr.ht>
+Signed-off-by: Alejandro Colomar <alx@kernel.org>
+Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
+---
+ src/gpasswd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/gpasswd.c b/src/gpasswd.c
+index 5983f787..2d8869ef 100644
+--- a/src/gpasswd.c
++++ b/src/gpasswd.c
+@@ -896,6 +896,7 @@ static void change_passwd (struct group *gr)
+ strzero (cp);
+ cp = getpass (_("Re-enter new password: "));
+ if (NULL == cp) {
++ memzero (pass, sizeof pass);
+ exit (1);
+ }
+
+--
+2.34.1
+
diff --git a/meta/recipes-extended/shadow/shadow.inc b/meta/recipes-extended/shadow/shadow.inc
index cf05a3af93..4014baddc1 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -17,6 +17,7 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.gz \
file://0001-Fix-can-not-print-full-login.patch \
file://CVE-2023-29383.patch \
file://0001-Overhaul-valid_field.patch \
+ file://CVE-2023-4641.patch \
"
SRC_URI:append:class-target = " \
--
2.34.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* [OE-core][mickledore 4/5] openssl: Upgrade 3.1.3 -> 3.1.4
2023-10-31 15:35 [OE-core][mickledore 0/5] Patch review Steve Sakoman
` (2 preceding siblings ...)
2023-10-31 15:35 ` [OE-core][mickledore 3/5] shadow: Fix CVE-2023-4641 Steve Sakoman
@ 2023-10-31 15:35 ` Steve Sakoman
2023-10-31 15:35 ` [OE-core][mickledore 5/5] linux-yocto: make sure the pahole-native available before do_kernel_configme Steve Sakoman
2023-10-31 15:55 ` [OE-core][mickledore 0/5] Patch review Richard Purdie
5 siblings, 0 replies; 8+ messages in thread
From: Steve Sakoman @ 2023-10-31 15:35 UTC (permalink / raw)
To: openembedded-core
From: Peter Marko <peter.marko@siemens.com>
https://github.com/openssl/openssl/blob/openssl-3.1/NEWS.md#major-changes-between-openssl-313-and-openssl-314-24-oct-2023
Major changes between OpenSSL 3.1.3 and OpenSSL 3.1.4 [24 Oct 2023]
* Mitigate incorrect resize handling for symmetric cipher keys and IVs. (CVE-2023-5363)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
.../openssl/{openssl_3.1.3.bb => openssl_3.1.4.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-connectivity/openssl/{openssl_3.1.3.bb => openssl_3.1.4.bb} (99%)
diff --git a/meta/recipes-connectivity/openssl/openssl_3.1.3.bb b/meta/recipes-connectivity/openssl/openssl_3.1.4.bb
similarity index 99%
rename from meta/recipes-connectivity/openssl/openssl_3.1.3.bb
rename to meta/recipes-connectivity/openssl/openssl_3.1.4.bb
index ff9df693b8..72338b0022 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.1.3.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.1.4.bb
@@ -18,7 +18,7 @@ SRC_URI:append:class-nativesdk = " \
file://environment.d-openssl.sh \
"
-SRC_URI[sha256sum] = "f0316a2ebd89e7f2352976445458689f80302093788c466692fb2a188b2eacf6"
+SRC_URI[sha256sum] = "840af5366ab9b522bde525826be3ef0fb0af81c6a9ebd84caa600fea1731eee3"
inherit lib_package multilib_header multilib_script ptest perlnative manpages
MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
--
2.34.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* [OE-core][mickledore 5/5] linux-yocto: make sure the pahole-native available before do_kernel_configme
2023-10-31 15:35 [OE-core][mickledore 0/5] Patch review Steve Sakoman
` (3 preceding siblings ...)
2023-10-31 15:35 ` [OE-core][mickledore 4/5] openssl: Upgrade 3.1.3 -> 3.1.4 Steve Sakoman
@ 2023-10-31 15:35 ` Steve Sakoman
2023-10-31 15:55 ` [OE-core][mickledore 0/5] Patch review Richard Purdie
5 siblings, 0 replies; 8+ messages in thread
From: Steve Sakoman @ 2023-10-31 15:35 UTC (permalink / raw)
To: openembedded-core
From: Xiangyu Chen <xiangyu.chen@windriver.com>
When using debug-btf.scc in a clean workspace, the CONFIG_MODULE_ALLOW_BTF_MISMATCH cannot
apply to kernel until clean the kernel code(bitbake linux-yocto -c cleanall) and rebuild.
After tracking the code, some options depend on CONFIG_PAHOLE_VERSION, it was generated by
scripts/pahole-version.sh in kernel, but during do_kernel_configme step, the pahole-native
is not available in sysroot-native, so need to wait pahole-native install to sysroot-native
before do_kernel_configme.
(cherry picked from commit 217a4db53edbd88001f6390bbff39e5dd3d137af)
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta/recipes-kernel/linux/linux-yocto.inc | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
index 04a8105e17..461e5684cd 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -65,7 +65,10 @@ KERNEL_DEBUG ?= ""
DEPENDS += '${@bb.utils.contains_any("ARCH", [ "x86", "arm64" ], "elfutils-native", "", d)}'
DEPENDS += "openssl-native util-linux-native"
DEPENDS += "gmp-native libmpc-native"
-DEPENDS += '${@bb.utils.contains("KERNEL_DEBUG", "True", "pahole-native", "", d)}'
+
+# Some options depend on CONFIG_PAHOLE_VERSION, so need to make pahole-native available before do_kernel_configme
+do_kernel_configme[depends] += '${@bb.utils.contains("KERNEL_DEBUG", "True", "pahole-native:do_populate_sysroot", "", d)}'
+
EXTRA_OEMAKE += '${@bb.utils.contains("KERNEL_DEBUG", "True", "", "PAHOLE=false", d)}'
do_devshell:prepend() {
--
2.34.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [OE-core][mickledore 0/5] Patch review
2023-10-31 15:35 [OE-core][mickledore 0/5] Patch review Steve Sakoman
` (4 preceding siblings ...)
2023-10-31 15:35 ` [OE-core][mickledore 5/5] linux-yocto: make sure the pahole-native available before do_kernel_configme Steve Sakoman
@ 2023-10-31 15:55 ` Richard Purdie
2023-10-31 16:15 ` Steve Sakoman
5 siblings, 1 reply; 8+ messages in thread
From: Richard Purdie @ 2023-10-31 15:55 UTC (permalink / raw)
To: Steve Sakoman, openembedded-core
On Tue, 2023-10-31 at 05:35 -1000, Steve Sakoman wrote:
> Please review this set of patches for mickledore and have comments back by
> end of day Thursday, November 2
>
> Passed a-full on autobuilder:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6123
>
> The following changes since commit e9ca1405b732720ff72d379e0262a78bfd2e7d53:
>
> busybox: Set PATH in syslog initscript (2023-10-19 04:34:38 -1000)
>
> are available in the Git repository at:
>
> https://git.openembedded.org/openembedded-core-contrib stable/mickledore-nut
> https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/mickledore-nut
>
> Peter Marko (1):
> openssl: Upgrade 3.1.3 -> 3.1.4
>
> Xiangyu Chen (4):
> grub2: fix CVE-2023-4692
> grub2: fix CVE-2023-4693
> shadow: Fix CVE-2023-4641
> linux-yocto: make sure the pahole-native available before
> do_kernel_configme
>
Some of these are not in nanbield :/
Cheers,
Richard
^ permalink raw reply [flat|nested] 8+ messages in thread