Yocto Project - User contributions [en]

CVE Status

2024-03-10T11:29:39Z

Simonew: /* CVE-2024-0684 (coreutils) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream, disputed by maintainer see https://lists.gnu.org/archive/html/bug-cpio/2024-03/msg00000.html

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25739 CVE-2024-25739] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25740 CVE-2024-25740] (linux-yocto) ===

CVE Status

2024-03-10T11:29:15Z

Simonew: /* CVE-2023-6780 (glibc) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream, disputed by maintainer see https://lists.gnu.org/archive/html/bug-cpio/2024-03/msg00000.html

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25739 CVE-2024-25739] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25740 CVE-2024-25740] (linux-yocto) ===

CVE Status

2024-03-10T11:28:31Z

Simonew: /* CVE-2023-6683 (qemu) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream, disputed by maintainer see https://lists.gnu.org/archive/html/bug-cpio/2024-03/msg00000.html

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25739 CVE-2024-25739] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25740 CVE-2024-25740] (linux-yocto) ===

CVE Status

2024-03-03T11:52:41Z

Simonew: /* CVE-2023-7216 (cpio) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] is merged to master

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream, disputed by maintainer see https://lists.gnu.org/archive/html/bug-cpio/2024-03/msg00000.html

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25739 CVE-2024-25739] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25740 CVE-2024-25740] (linux-yocto) ===

CVE Status

2024-03-03T11:51:55Z

Simonew: /* CVE-2024-24860 (linux-yocto) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] is merged to master

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25739 CVE-2024-25739] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25740 CVE-2024-25740] (linux-yocto) ===

CVE Status

2024-02-25T12:55:53Z

Simonew: /* CVE-2021-3864 (linux-yocto) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] is merged to master

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:54:07Z

Simonew: /* CVE-2023-3180 (qemu) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] is merged to master

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:52:04Z

Simonew: /* CVE-2023-6683 (qemu) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] is merged to master

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:35:26Z

Simonew: /* CVE-2023-6693 (qemu) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:35:04Z

Simonew: /* CVE-2023-5088 (qemu) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:34:43Z

Simonew: /* CVE-2023-4693 (grub:grub-efi:grub-native) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:34:32Z

Simonew: /* CVE-2023-4692 (grub) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:34:16Z

Simonew: /* CVE-2023-38559 (ghostscript) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:33:56Z

Simonew: /* CVE-2023-3164 (tiff) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 CVE-2023-38559] (ghostscript) ===

Fix https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1
Present in >= 10.02.0 (OE-core ghostscript = 10.02.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:33:34Z

Simonew: /* CVE-2023-3019 (qemu) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 CVE-2023-3164] (tiff) ===

Upstream issue https://gitlab.com/libtiff/libtiff/-/issues/542 closed as "wontfix-unmaintained"
Only affect the tiffcrop tool not compiled by default since 4.6.0 (OE-Core = 4.6.0).
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 CVE-2023-38559] (ghostscript) ===

Fix https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1
Present in >= 10.02.0 (OE-core ghostscript = 10.02.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-25T12:33:12Z

Simonew: /* CVE-2023-25584 (binutils) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 CVE-2023-3019] (qemu) ===

Fixed in 8.2.0 with 9050f976e447444ea6ee2ba12c9f77e4b0dc54bc. NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 CVE-2023-3164] (tiff) ===

Upstream issue https://gitlab.com/libtiff/libtiff/-/issues/542 closed as "wontfix-unmaintained"
Only affect the tiffcrop tool not compiled by default since 4.6.0 (OE-Core = 4.6.0).
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 CVE-2023-38559] (ghostscript) ===

Fix https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1
Present in >= 10.02.0 (OE-core ghostscript = 10.02.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

User:Simonew

2024-02-20T13:46:30Z

Simonew:

When I find stuff missing/outdated here - I try to add it directly.

Patchtest

2024-02-20T13:45:12Z

Simonew:

== Patchtest ==

Patchtest is a tool designed for improving the quality of Yocto Project and OpenEmbedded contributors' patch submissions, while simultaneously reducing the level of review effort required from project maintainers. It does this by providing a set of scripts that users can test their patches with prior to submission ("host" mode), and which can be used as part of an automated service that provides periodic feedback for patches received by Patchwork ("guest" mode).

=== Using Patchtest ===

See the [https://git.yoctoproject.org/poky/tree/scripts/patchtest.README patchtest README] for instructions on how to use patchtest in your local workspace, and the [https://git.yoctoproject.org/meta-patchtest/tree/README.md meta-patchtest README] for details on automated/guest mode setup.

=== Patchtest "FAIL:" Descriptions ===

The patchtest feedback email is designed to provide concise instructions when one or more of the tests has failed, but additional information on specific failures is provided below:

{| class="wikitable" style="margin:auto"
|-
! Testcase !! Details !! Further information
|-
| test_upstream_status_presence_format || This testcase checks if newly introduced *.patch files contain a valid upstream status, if not included the testcase fails || https://docs.yoctoproject.org/dev/contributor-guide/recipe-style-guide.html?highlight=upstream+status#patch-upstream-status
|-
| test_signed_off_by_presence || This testcase checks if newly introduced *.patch files contain a Signed-off-by, if not included the testcase fails || https://docs.yoctoproject.org/dev/contributor-guide/recipe-style-guide.html?highlight=signed+off#patch-upstream-status
|-
| test_cve_tag_format || Whenever a submission adds a CVE patch, patchtest will check both the patch '''and the parent mbox's commit message''' for a "CVE: CVE-YYYY-XXXX" tag. While this has historically not been required, including the tag in both locations aids review and maintenance. || https://docs.yoctoproject.org/dev/contributor-guide/recipe-style-guide.html?highlight=signed+off#cve-patches
|-
| test_signed_off_by_presence || This testcase checks if the tested patch contains a valid Signed-off-by || If it fails you can add it manually or with "git commit --amend -s", See also https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#implement-and-commit-changes
|-
| test_shortlog_format || This testcases checks the format of the shortlog (header line in the commit message). The expected format is: <target>: <summary>, where component is a recipe name or the short form path to the file being changed || https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#implement-and-commit-changes
|-
| test_shortlog_length || This failure indicates that the shortlog (i.e. the subject line) for the patch is so long that it may not be easily readable on some mail clients. Some subject prefixes (e.g. the branch name when submitting a patch for an older release) may unavoidably inflate the length, but the shortlog should be kept as short and concise as possible so that it is clear what the patch does and what it changes. Extra information can always be provided in the commit message. || https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#implement-and-commit-changes
|-
| test_series_merge_on_head || Checks if series applies on top of target branch. Temporary disabled, but ensure your series applies cleanly || https://docs.yoctoproject.org/overview-manual/development-environment.html?highlight=git#git
|-
| test_target_mailing_list || Checks if series is sent to the correct mailing list for all files in the series. Poky is a combo layer combining bitbake, openembedded-core, meta-yocto and yocto-docs. Please create and submit patches against the individual components. || https://docs.yoctoproject.org/contributor-guide/identify-component.html
|-
| test_mbox_format || Checks if the patch has no malformed diff lines and can be applied cleanly. || Create the series again using git-format-patch and ensure it applies using git am. See also: https://docs.yoctoproject.org/overview-manual/development-environment.html?highlight=git#git
|-
| test_commit_message_presence || This testcases fails if a submission has an empty commit message. Provide for example detailed information on what you changed and why, how you tested it. || https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#implement-and-commit-changes
|-
| test_bugzilla_entry_format || Checks that the Bugzilla issue ID, if mentioned in the commit message, is correctly formatted. Format is: "[YOCTO #<bugzilla ID>]. || https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#implement-and-commit-changes
|-
| test_author_valid || A patch authored by an invalid author was detected. || You can amend the author via git commit --amend
|-
| test_non_auh_upgrade || A patch authored by the Auto-Upgrade Helper (AUH) was detected. These patches are meant to provide maintainers with a sanity check for recipe upgrades and a starting point for testing them, so patches submitted with that authorship are marked as failures to indicate that they have not been fully validated. || For a overview of AUH see also: https://docs.yoctoproject.org/dev/dev-manual/upgrading-recipes.html#using-the-auto-upgrade-helper-auh
|-
| test_pylint || Fails if patch contains .py files and pylint detected new issues if the patch is applied || Check changes with pylint and amend patch
|-
| test_license_presence || Checks to ensure that LICENSE is set for a newly added recipe. || https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-LICENSE
|-
| test_lic_files_chksum_presence || Checks to ensure that LIC_FILES_CHKSUM is present, if not then this test will fail. || https://docs.yoctoproject.org/dev/dev-manual/licenses.html#tracking-license-changes
|-
| test_lic_files_chksum_modified_not_mentioned || Checks to ensure that any changes made to LIC_FILES_CHKSUM lines (including checksums for new files) are accounted for in the commit message with at least one "License-Update: <reason>" tag. If this is not present, then this test will fail. || https://docs.yoctoproject.org/dev/contributor-guide/recipe-style-guide.html?highlight=license+update#license-updates
|-
| test_max_line_length || Checks if any line in the meta-data changed in series contains no lines that are longer that 200 characters. || Please ensure that lines do not exceed this length and amend your patch
|-
| test_src_uri_left_files || Checks if all files removed from SRC_URI are also removed from the tree. || Please remove files that are not included in the SRC_URI from the tree as wll, e.g. with git rm <file>
|-
| test_summary_presence || Checks if SUMMARY is set for newly added recipes. Should be set to a short description of the package created by the recipe. || https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-SUMMARY
|-
| test_cve_check_ignore || Fails if the deprecated CVE_CHECK_INGNORE is used instead of CVE_STATUS. || https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-CVE_STATUS
|}

==== Tests failed for the patch, but the results log could not be processed due to excessive result line length. ====

The patchtest-send-results script checks the test results' maximum line length to help ensure that no unintended and/or malicious code is sent to the mailing list with the results. If this message is present, the user should re-test their patch(es) locally using the '''patchtest''' script in openembedded-core/scripts before further escalation. If the issue persists after re-testing and re-submission it should be reported on the Yocto Project [https://bugzilla.yoctoproject.org/ Bugzilla] under the "Yocto Project Subprojects" -> "Patchtest" category with a "Major" priority (include the patch file as an attachment).

=== Submitting Bug Reports ===

If you suspect there is an issue with the patchtest feedback emails, the service itself, or any of the documentation, please submit an issue on the Yocto Project Bugzilla [https://bugzilla.yoctoproject.org/ Bugzilla] under the "Yocto Project Subprojects" -> "Patchtest" category.

=== Patchtest Architecture Notes ===

{| class="wikitable" style="margin:align-left"
|+ Test Suite Details
|-
! Test Name !! Category !! Uses Tinfoil !! Notes
|-
| test_upstream_status_presence_format || TestPatch || No ||
|-
| test_signed_off_by_presence || TestPatch || No || Same test name as similar test in TestMbox
|-
| test_cve_tag_format || TestPatch || No ||
|-
| test_signed_off_by_presence || TestMbox || No || Same test name as similar test in TestPatch
|-
| test_shortlog_format || TestMbox || No ||
|-
| test_shortlog_length || TestMbox || No ||
|-
| test_series_merge_on_head || TestMbox || No || Temporarily disabled
|-
| test_target_mailing_list || TestMbox || No ||
|-
| test_mbox_format || TestMbox || No ||
|-
| test_commit_message_presence || TestMbox || No ||
|-
| test_bugzilla_entry_format || TestMbox || No ||
|-
| test_author_valid || TestMbox || No ||
|-
| test_non_auh_upgrade || TestMbox || No ||
|-
| test_pylint || PyLint || No ||
|-
| test_license_presence || TestMetadata || Yes ||
|-
| test_lic_files_chksum_presence || TestMetadata || Yes ||
|-
| test_lic_files_chksum_modified_not_mentioned || TestMetadata || No ||
|-
| test_max_line_length || TestMetadata || No ||
|-
| test_src_uri_left_files || TestMetadata || Yes || Has a linked pretest: pretest_src_uri_left_files
|-
| test_summary_presence || TestMetadata || Yes ||
|-
| test_cve_check_ignore || TestMetadata || Yes ||
|}

CVE Status

2024-02-18T22:38:43Z

Simonew: /* CVE-2023-7216 (cpio) */

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 CVE-2023-3019] (qemu) ===

Fixed in 8.2.0 with 9050f976e447444ea6ee2ba12c9f77e4b0dc54bc. NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 CVE-2023-3164] (tiff) ===

Upstream issue https://gitlab.com/libtiff/libtiff/-/issues/542 closed as "wontfix-unmaintained"
Only affect the tiffcrop tool not compiled by default since 4.6.0 (OE-Core = 4.6.0).
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-25584 CVE-2023-25584] (binutils) ===

Merged fix in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=77c225bdeb410cf60da804879ad41622f5f1aa44. Present in binutils >=2.40
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 CVE-2023-38559] (ghostscript) ===

Fix https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1
Present in >= 10.02.0 (OE-core ghostscript = 10.02.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===
Open upstream

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-18T22:38:09Z

Simonew:

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 CVE-2023-3019] (qemu) ===

Fixed in 8.2.0 with 9050f976e447444ea6ee2ba12c9f77e4b0dc54bc. NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 CVE-2023-3164] (tiff) ===

Upstream issue https://gitlab.com/libtiff/libtiff/-/issues/542 closed as "wontfix-unmaintained"
Only affect the tiffcrop tool not compiled by default since 4.6.0 (OE-Core = 4.6.0).
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-25584 CVE-2023-25584] (binutils) ===

Merged fix in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=77c225bdeb410cf60da804879ad41622f5f1aa44. Present in binutils >=2.40
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 CVE-2023-38559] (ghostscript) ===

Fix https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1
Present in >= 10.02.0 (OE-core ghostscript = 10.02.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

CVE Status

2024-02-18T21:27:12Z

Simonew: triage 18-feb-2024

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 CVE-2023-3019] (qemu) ===

Fixed in 8.2.0 with 9050f976e447444ea6ee2ba12c9f77e4b0dc54bc. NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 CVE-2023-3164] (tiff) ===

Upstream issue https://gitlab.com/libtiff/libtiff/-/issues/542 closed as "wontfix-unmaintained"
Only affect the tiffcrop tool not compiled by default since 4.6.0 (OE-Core = 4.6.0).
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-25584 CVE-2023-25584] (binutils) ===

Merged fix in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=77c225bdeb410cf60da804879ad41622f5f1aa44. Present in binutils >=2.40
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 CVE-2023-38559] (ghostscript) ===

Fix https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1
Present in >= 10.02.0 (OE-core ghostscript = 10.02.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 CVE-2023-6240] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 CVE-2023-6356] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 CVE-2023-6535] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 CVE-2023-6536] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 CVE-2023-7216] (cpio) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 CVE-2024-0684] (coreutils) ===
Fix available, but not in any release yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24860 CVE-2024-24860] (linux-yocto) ===

Header template:

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE CVE] (RECIPE) ===
-->

Setting up a production instance of Toaster

2024-02-18T00:42:24Z

Simonew:

[[Category:Toaster]]
----
{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is the development version of the documentation to provide the latest information, if you're using a release please refer to [https://docs.yoctoproject.org/toaster-manual/index.html the published manual]'''
|}
----
A production instance of Toaster is one in which you wish to share the Toaster instance with remote and multiple users. It is also the setup which can cope with heavier loads on the web service. These instructions setup toaster in Build mode where builds and projects are run, viewed and defined by the Toaster web interface.

== Requirements ==
* [http://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html#packages Build requirements]
* Apache webserver
* mod-wsgi for Apache webserver
* Mysql database server

Ubuntu 14.04.3:
<code>
$ sudo apt-get install apache2 libapache2-mod-wsgi mysql-server python-virtualenv libmysqlclient-dev python-dev python-mysqldb
</code>

Fedora 22/RH:
<code>
$ sudo dnf install httpd mod_wsgi python-virtualenv gcc mysql-devel
</code>

== Installation ==

'''1.''' Checkout a copy of Poky into the web server directory. We're going to be using /var/www/toaster.
<code>
$ mkdir -p /var/www/toaster
$ cd /var/www/toaster/
$ git clone git://git.yoctoproject.org/poky
$ cd poky
$ git checkout jethro # change for any release name required
</code>

'''2.''' Initialise a virtualenv and install Toaster dependencies. (Use virtualenv to keep the python packages isolated from your system provided packages - not required but recommended, alternative use your OS's package manager to install the packages)

<code>
$ cd /var/www/toaster/
$ virtualenv venv
$ source ./venv/bin/activate
$ pip install -r ./poky/bitbake/toaster-requirements.txt
$ pip install mysqlclient
</code>

'''3.''' Configure toaster edit /var/www/toaster/poky/bitbake/lib/toaster/toastermain/settings.py

Edit the DATABASE settings:
<code>
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'toaster_data',
'USER': 'toaster',
'PASSWORD': 'yourpasswordhere',
'HOST': 'localhost',
'PORT': '3306',
}
</code>

Edit the [https://docs.djangoproject.com/en/1.8/howto/deployment/checklist/#secret-key SECRET_KEY]:
<code>
SECRET_KEY = 'YOUR SECRET RANDOM KEY HERE'
</code>

Edit the STATIC_ROOT:
<code>
STATIC_ROOT = '/var/www/toaster/static_files/'
</code>

'''4.'''' Now add the database and user to your mysql server that we just defined
<code>
$ mysql -u root -p
mysql> CREATE DATABASE toaster_data;
mysql> CREATE USER 'toaster'@'localhost' identified by 'yourpasswordhere';
mysql> GRANT all on toaster_data.* to 'toaster'@'localhost';
mysql> quit
</code>
n.b. You may want to decide on fewer [https://dev.mysql.com/doc/refman/5.1/en/grant.html privileges] to the toaster user.

'''5.''' Get toaster to create the database schema, default data, update the TOASTER_DIR which is the build work dir and collect up the statically served files

<code>
$ cd /var/www/toaster/poky/
$ ./bitbake/lib/toaster/manage.py migrate
$ ./bitbake/lib/toaster/manage.py loadconf ./meta-yocto/conf/toasterconf.json
$ TOASTER_DIR=/var/www/toaster/poky/ ./bitbake/lib/toaster/manage.py checksettings
$ ./bitbake/lib/toaster/manage.py lsupdates
$ ./bitbake/lib/toaster/manage.py collectstatic
</code>

'''6.''' Add a config file for Toaster to your Apache web server's configurations available directory.

Ubuntu/Debian put it here: /etc/apache2/conf-available/toaster.conf
Fedora/RH usually here: /etc/httpd/conf.d/toaster.conf
<code>

Alias /static /var/www/toaster/static_files
<Directory /var/www/toaster/static_files>
Order allow,deny
Allow from all
Require all granted
</Directory>
WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/poky/bitbake/lib/toaster:/var/www/toaster/venv/lib/python2.7/site-packages
WSGIScriptAlias / "/var/www/toaster/poky/bitbake/lib/toaster/toastermain/wsgi.py"
<Location />
WSGIProcessGroup toaster_wsgi
</Location>

</code>

In Ubuntu/Debain you will need to enable the config and module in Apache webserver
<code>
$ sudo a2enmod wsgi
$ sudo a2enconf toaster
</code>

Restart Apache web server to make sure all new configuration is loaded

Ubuntu/Debian:
<code>
$ sudo service apache2 restart
</code>

Fedora/RH:
<code>
$ sudo service httpd restart
</code>

'''7.''' Install the build runner service

This service needs to be running in order to dispatch builds the command that needs to be run is:

<code>
$ source oe-init-build-env
$ source toaster start noweb
</code>

Example upstart service /etc/init/toaster-buildservice.conf :
<pre>
author "Michael W"
description "start and stop toaster build service"
version "1.0"

start on started networking
stop on runlevel [!2345]

respawn

script
exec su toasterbuilder -c "cd /var/www/toaster/poky && source oe-init-build-env && source toaster start noweb"
end script
</pre>

Example systemd service usually in /lib/systemd/system/toaster.service:
<pre>
[Unit]
Description=Toaster runbuilds

[Service]
Type=forking
User=toaster
ExecStart=/var/www/toaster/toaster-service.sh start
ExecStop=/var/www/toaster/toaster-service.sh stop

[Install]
WantedBy=multi-user.target
</pre>
script /var/www/toaster/toaster-service.sh:
<pre>

#!/bin/bash

cd /var/www/toaster/poky/

source oe-init-build-env
if [ "$1" == 'start' ]; then
source ../bitbake/bin/toaster start noweb
fi

if [ "$1" == 'stop' ]; then
source ../bitbake/bin/toaster stop
fi
</pre>

N.b. You may wish to add a service entry to your OS's init system so that it starts up on start up as well as adding a dedicated user.

Now open up a browser and you can start using Toaster!

CVE Status

2024-02-12T17:45:10Z

Simonew: mentioned when NVD was pinged 12/02/2024.

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 CVE-2023-3019] (qemu) ===

Fixed in 8.2.0 with 9050f976e447444ea6ee2ba12c9f77e4b0dc54bc. NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 CVE-2023-3164] (tiff) ===

Upstream issue https://gitlab.com/libtiff/libtiff/-/issues/542 closed as "wontfix-unmaintained"
Only affect the tiffcrop tool not compiled by default since 4.6.0 (OE-Core = 4.6.0).
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-37769 CVE-2023-37769] (pixman) ===

Appears to be a floating point exception in a test, should verify that the crash is in the test code and not the library. [https://gitlab.freedesktop.org/pixman/pixman/-/issues/76 This ticket] has the details.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-25584 CVE-2023-25584] (binutils) ===

Merged fix in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=77c225bdeb410cf60da804879ad41622f5f1aa44. Present in binutils >=2.40
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 CVE-2023-38559] (ghostscript) ===

Fix https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1
Present in >= 10.02.0 (OE-core ghostscript = 10.02.1)
NVD pinged 06/02/2024. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-48795 CVE-2023-48795] (openssh) ===

Fix WIP : https://lists.openembedded.org/g/openembedded-core/topic/103546397#193372

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51384 CVE-2023-51384] (openssh) ===

Fix WIP : https://lists.openembedded.org/g/openembedded-core/topic/103546397#193372

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51385 CVE-2023-51385] (openssh) ===

Fix WIP : https://lists.openembedded.org/g/openembedded-core/topic/103546397#193372

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe. NVD pinged 12/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

CVE Status

2024-02-11T17:26:29Z

Simonew: Update with new/removed CVEs cw 06/24

This is a list of CVEs which are currently being reported as open, and the current state.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 CVE-2019-14899] (linux-yocto) ===

Claims to be about breaking into VPN tunnels. OpenVPN dispute, Red Hat think it might actually have a larger scope but also the paper is misleading.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 CVE-2021-3714] (linux-yocto) ===

Flaw in kernel memory de-duplication. Still an issue, albeit minor.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 CVE-2021-3864] (linux-yocto) ===

Issue with suid binaries and coredumps. Last known progress on mitigating was [https://lore.kernel.org/lkml/CAAq0SUmw3fGtwDifbBMrD7jgPBGQb7uC0K9hJetVTRQO7boPtA@mail.gmail.com/t/#u this thread].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 CVE-2022-3219] (gnupg) ===

Hypothetical DoS. A patch [https://dev.gnupg.org/D556 was proposed] but hasn't been reviewed or merged.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 CVE-2022-0400] (linux-yocto) ===

Out-of-bounds read in the SMC stack. Details are still embargoed so can't tell what this actually impacts.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 CVE-2022-1247] (linux-yocto) ===

Race in the X.25 AF_ROSE implementation, so only an issue if <tt>CONFIG_ROSE</tt> is enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 CVE-2022-4543] (linux-yocto) ===

aka EntryBleed. Vulnerable on x86-64 systems.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 CVE-2022-38096] (linux-yocto) ===

Bug in vmwgfx driver, still open. Mitigated if CONFIG_DRM_VMWGFX is not enabled.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 CVE-2022-46456] (nasm) ===

Buffer overflow, [https://bugzilla.nasm.us/show_bug.cgi?id=3392814 still open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 CVE-2023-0687] (glibc) ===

Bad CPE, should be marked as fixed in 2.38. Emailed NIST, data not updated yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 CVE-2023-1386] (qemu) ===

Still [https://github.com/v9fs/linux/issues/29 open upstream].

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 CVE-2023-3019] (qemu) ===

Fixed in 8.2.0 with 9050f976e447444ea6ee2ba12c9f77e4b0dc54bc. NVD pinged 06/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 CVE-2023-3164] (tiff) ===

Upstream issue https://gitlab.com/libtiff/libtiff/-/issues/542 closed as "wontfix-unmaintained"
Only affect the tiffcrop tool not compiled by default since 4.6.0 (OE-Core = 4.6.0).
NVD pinged 06/02/2024.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 CVE-2023-3180] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/9d38a8434721a6479fe03fb5afb150ca793d3980 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 CVE-2023-3354] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 CVE-2023-3640] (linux-yocto) ===

CPU-level address leak specific to x86, still an issue.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 CVE-2023-3772] (linux-yocto) ===

Merged in 00374d9b6d9f932802b55181be9831aa948e5b7c, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 CVE-2023-3773] (linux-yocto) ===

Merged in 5e2424708da7207087934c5c75211e8584d553a0, needs backport.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 CVE-2023-4010] (linux-yocto) ===

Hang in USB subsystem. No fix yet.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 CVE-2023-4128] (linux-yocto) ===

Merged in 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81, needs backporting.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 CVE-2023-4135] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-37769 CVE-2023-37769] (pixman) ===

Appears to be a floating point exception in a test, should verify that the crash is in the test code and not the library. [https://gitlab.freedesktop.org/pixman/pixman/-/issues/76 This ticket] has the details.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 CVE-2023-40360] (qemu) ===

[https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98 Fixed] in 8.1.0.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 CVE-2023-4569] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/346.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 CVE-2023-4611] (linux-yocto) ===

Fixed upstream. LKC https://github.com/nluedtke/linux_kernel_cves/issues/347.

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 CVE-2023-5088] (qemu) ===

Fix merged https://github.com/qemu/qemu/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e
Present in >=8.2.0 (OE-core qemu = 8.2.1)
NVD pinged 06/02/2024

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4692 CVE-2023-4692] (grub) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4693 CVE-2023-4693] (grub:grub-efi:grub-native) ===

(in NTFS support) : Fix merged : e58b870ff926415e23fc386af41ff81b2f588763 + 6 parents , released in 2.12
OE-Core grub = 2.12
NVD pinged 06/02/2024

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 CVE-2023-6683] (qemu) ===

Patch posted : [https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html ui/clipboard: avoid crash upon request when clipboard peer is no] not merged yet

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 CVE-2023-6693] (qemu) ===

Backported upstream 939a09575fff7048446e36ce438fa7be6e251d41 in v8.2.1. CPE change request sent to NVD 07/02/2024

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-25584 CVE-2023-25584] (binutils) ===

Merged fix in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=77c225bdeb410cf60da804879ad41622f5f1aa44. Present in binutils >=2.40
NVD pinged 06/02/2024

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 CVE-2023-38559] (ghostscript) ===

Fix https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1
Present in >= 10.02.0 (OE-core ghostscript = 10.02.1)
NVD pinged 06/02/2024

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 CVE-2023-42363] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15865"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 CVE-2023-42364] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15868"

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 CVE-2023-42365] (busybox) ===

Upstream bug still open https://bugs.busybox.net/show_bug.cgi?id=15871 "

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 CVE-2023-42366] (busybox) ===

Patch available (not merged yet) : [https://bugs.busybox.net/attachment.cgi?id=9697&action=edit Attachment 9697 Details for Bug 15874 – PATCH awk.c: fix CVE-2023-42366 (bug #15874)]

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-48795 CVE-2023-48795] (openssh) ===

Fix WIP : https://lists.openembedded.org/g/openembedded-core/topic/103546397#193372

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51384 CVE-2023-51384] (openssh) ===

Fix WIP : https://lists.openembedded.org/g/openembedded-core/topic/103546397#193372

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51385 CVE-2023-51385] (openssh) ===

Fix WIP : https://lists.openembedded.org/g/openembedded-core/topic/103546397#193372

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 CVE-2023-51767] (openssh) ===

"openssh: authentication bypass via row hammer attack"
Upstream bug : https://bugzilla.mindrot.org/show_bug.cgi?id=3656 (still open, no patch)
Real-world impacts seem quite low

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 CVE-2023-6780] (glibc) ===
Fixed in 2.39 already wrong cpe

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 CVE-2023-21803] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 CVE-2023-24857] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 CVE-2023-24858] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 CVE-2023-24859] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 CVE-2023-24861] (linux-yocto) ===

=== [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 CVE-2023-25864] (linux-yocto) ===

Main Page

2024-01-26T21:02:37Z

Simonew:

== Welcome to the Yocto Project Wiki! ==
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it's all about.

===Where to Start?===
If you're new to Yocto take a look at the '''[[Glossary]]''' so you're familiar with the terms used in this wiki and the project documentation. Then take a look at the [https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html '''Quick Start Guide''']. You can follow the steps in this document to clone the poky repository, quickly configure your build environment, and then try a build. Corporate firewalls can be problematic so network proxy configurations are detailed on the '''[[Working Behind a Network Proxy]]''' page. We advise you go straight for the [[Working_Behind_a_Network_Proxy#Option_2:_Chameleonsocks| Chameleonsocks option]].

===Where to Next?===
Thanks to the quick start guide, it's pretty easy to get your first Linux image build and running. Here are some places to look for help when improving your Yocto skills.
* The [https://linuxfoundation.org Linux Foundation] have some great [https://docs.google.com/presentation/d/1LmI3mHoD_Dzl8wplIYcUBrFF8BzDb_EadTvfbnpSK7Q/edit training slides]. There is also an [https://docs.google.com/presentation/d/1HoDtyN5SzlmuTN47ab4Y7w_i6c_VEW6EBUD944ntf38/edit#slide advanced slide deck] for more experienced users.
* The first tool you'll need to get familiar with is '''bitbake''', so reading through the [[https://docs.yoctoproject.org/dev/bitbake.htmluser manual] is recommended. You don't need to understand it all right now, but bookmark this page for reference. Implementation of bitake is covered in the [[Bitbake Internals Primer]]
* Once you start adding packages and configuring your image to create your own distribution, things can go wrong and it can hard to track down the root cause. There is no shortage of Yocto documentation resource, but if you're not exactly sure what you're looking for this '''[[Documentation Decoder]]''' will help you out. Also take a look at the [https://wiki.yoctoproject.org/wiki/Cookbook '''Cookbook'''] and [https://wiki.yoctoproject.org/wiki/Technical_FAQ troubleshooting guide]. Also [https://www.yoctoproject.org/community/learn/#books these books] are helpful.
* Some new tools such as [https://docs.yoctoproject.org/dev/toaster-manual/index.html Toaster], [[Extensible SDK]] and [https://github.com/crops CROPS] are making it easier to get the best out of Yocto on Windows and Mac OS X. Take a look at the new workflow in [[Developer Workflow Improvements]].
* There is also a [https://wiki.yoctoproject.org/wiki/TipsAndTricks '''Tips and Tricks'''] section where more experienced developers contribute to articles that will help those new to Yocto Project.
* You can also read and participate on the [https://lists.yoctoproject.org mailing lists] - start with the [https://lists.yoctoproject.org/g/yocto main list] first - and the IRC channel. More information about the Yocto Project mailing lists, IRC and Matrix channels can be found [https://www.yoctoproject.org/community/mailing-lists/ here].

== Project planning ==

=== Project Status and Schedule ===
* [[Weekly_Status]]
* Testresults - https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults

=== Future Directions ===
* [[Future_Directions]]

=== Outdated Project planning pages ===
The following pages contain outdated Project planning information:

* [[Yocto Feature Summary]] (Current and Next)
* [[Planning]]

== Documentation ==

* [[Documentation Decoder]]

=== Improvement ideas ===

* [[Documentation Production Workflow]]

== Release Engineering ==

* [[Yocto Release Engineering | Yocto Project Release Engineering]]
* [[Yocto Release Engineering | Release Activity (with status, version info, QA links, etc)]]

== QA & Automation ==

* [[The_Yocto_Autobuilder| The Yocto Project Autobuilder]]
* [[QA| Yocto Project QA Main Page]]
* [[QA/Archive| Yocto Project QA Test Report Archive ]]

== Quick guide for newcomers ==

If you are new to the project and are willing to contribute, please refer to our [[Newcomers|guide for newcomers]].

== TSC ==
* Yocto Project Technical Steering Committee [[TSC]]

== Wiki reference sitemap ==
* [[Glossary]]
* [[Working Behind a Network Proxy]]
* [[FAQ]] and [[Technical FAQ]]. These need to be unified.
* [[Cookbook]] and [[TipsAndTricks | Tips and Tricks]]. Need clear messaging on how these should be differentiated.
* [[Developer Workflow Improvements]], including [[Nodejs Workflow Improvements]]
* [[Bug_Triage | Bug Triage Reference ]]
* [[Planning and Governance]]
* [[Community Guidelines]]
* [[Yocto Release Engineering | Yocto Project Release Engineering]]
* [[License Infrastructure Interest Group | License Infrastructure]]
* [[Processes and Activities]]
* [[Member Technical Contacts]]
* [[Projects]]
* [[Security]] - find out what we do about CVEs and security
* [[Yocto Interest Groups]]
* [[Toaster]] - the web interface
* [[YoctoProjectEvents]] - links to YoctoProject/OpenEmbedded related conferences and events
* [[Archive]] - Graveyard for out of date articles.

== Other resources ==
* [http://yoctoproject.org Yocto Project Front Page]
* [http://git.yoctoproject.org/ Yocto Project Git Source Repos]
* [https://docs.yoctoproject.org/ Yocto Project Documentation]
* [https://bugzilla.yoctoproject.org/ Yocto Project Bugzilla]
* [https://www.yoctoproject.org/tools-resources/community/mailing-lists Yocto Project Mailing Lists]
* [http://recipes.yoctoproject.org/rrs Yocto Project Recipe Reporting System]
* [https://autobuilder.yoctoproject.org/typhoon Yocto Project Autobuilder]
* [http://downloads.yoctoproject.org/releases/yocto/ Yocto Project Releases Downloads]
* [http://autobuilder.yoctoproject.org/pub/nightly/ Yocto Project Nightly Build Images]
* [http://downloads.yoctoproject.org/mirror/sources/ Upstream Sources Mirror]
* [http://www.openembedded.org/wiki/Main_Page OpenEmbedded Wiki]
* [http://cgit.openembedded.org/ OpenEmbedded Git Repos]
* [http://layers.openembedded.org/ OpenEmbedded Community Layers]
* [http://patchwork.openembedded.org/ OpenEmbedded Patch Tracking System]
* '''IRC''': [https://libera.chat/ irc.libera.chat]
:* #yocto - Public discussions on the Yocto Project.
:* #oe - Public discussions on OpenEmbedded Core.

Patchtest

2024-01-14T11:05:33Z

Simonew: Patchtest Architecture Notes: Add test_cve_check_ignore

How do I

2023-12-27T18:34:30Z

Simonew: Fix syntax

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How do I create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all *files* (not symlinks) in your download directory to the desired source mirror directory. Test by setting the variables below in <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
BB_NO_NETWORK = "1"

If you are building with <code>BB_NO_NETWORK</code> and using external layers that are not part of the base Yocto distribution, be aware that recipes which:

# Specify a Git repo as the source, and,
# Specify the revision to be built using a tag name

will cause your build to abort when Bitbake tries to run <code>git ls-remote</code> to resolve the tag name and is unable to access the network. So don't specify <code>SRC_URI</code> like this:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"</nowiki>

Instead, use:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"</nowiki>
SRCREV = "8885ced062131214448fae056ef453f094303805"

Before putting together your pre-mirror, this command can be used from
your top-level source directory to identify recipes that might be
problematic with <code>BB_NO_NETWORK</code> enabled:

find -name "*.inc" -o -name "*.bb" | xargs grep -li "git;tag="

== Q: How do I put Yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa := "5"

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

IMAGE_INSTALL:append = " hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

==Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? ==

'''A:''' You should read the [https://wiki.yoctoproject.org/wiki/Build_Performance Build Performance] wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

==Q: How do I get the networking to function on an Acer Aspire One n450 based netbook when using the meta-n450 BSP? ==

'''A:''' While the n450 BSP will boot on the Acer AO532h netbook, the BSP does not enable the Atheros AR5B95 Wireless and AR8132 fast ethernet adapters. The Linux Yocto 3.2 kernel has these drivers, but they are not enabled. All you have to do is to create a Config Fragment file with a .cfg extension in a new directory called 'linux-yocto' in the BSP recipes-kernel/linux directory. The new 'linux-yocto' directory will be at the same level as the linux-yocto_3.2.bbappend file. You will also need to add the following statement to the .bbappend file:

SRC_URI += "file://myconfig.cfg"

The recipes-kernel/linux/linux-yocto/myconfig.cfg needs to contain the following 2 lines:

CONFIG_ATH9K_PCI=y

CONFIG_ATL1C=y

==Q: How do I build the build appliance? ==
'''A:''' Update the MACHINE variable to "qemux86-64" or "qemux86" in your <code>conf/local.conf</code> :

Then, run this command:
# bitbake build-appliance-image

The resulting images (*.vmdk, *.vmx, *.vmxf) will be present in the "tmp/deploy/images" folder
ie:

# unzip Yocto_Build_Appliance.zip
# cd Yocto_Build_Appliance
# ls
Yocto_Build_Appliance.vmdk
Yocto_Build_Appliance.vmx
Yocto_Build_Appliance.vmxf

==Q: How do I build an image without GPLv3 Licensed packages ? ==
'''A:''' Add the line 'INCOMPATIBLE_LICENSE = "GPLv3"' in your <code>conf/local.conf</code> and ensure you have the GPLv2 replacement libraries. (Caveat emptor; they are not as well maintained.) From the Yocto Mega-Manual 2.4;

"If you use INCOMPATIBLE_LICENSE to exclude GPLv3 or set PREFERRED_VERSION to substitute a GPLv2 version of a GPLv3 recipe, then you must add the meta-gplv2 layer to your configuration."

Then, build the image:
# bitbake <image-name>

==Q: How do I ensure that I am using the latest upstream version of the package? ==
'''A:''' Add this line 'INHERIT += "distrodata"' in your <code>conf/local.conf</code> :

After that, run this command in the build directory:
# bitbake -c checkpkg <package>
Then, check the 'Version' and 'Upver' fields in the below listed file:
# gedit tmp/log/checkpkg.csv

If those versions are same, then we have the latest upstream version of package

==Q: How do I get a list of CVEs patched? ==
'''A:''' cve-check is available from 2.2 release (meta/recipes-core/meta/cve-update-nvd2-native.bb is used for acessing the new NVD database 2.0 API, meta/classes/cve-check.bbclass implements the check of recipes against CVEs).

To run it just inherit the class in conf/local.conf file:

# INHERIT += "cve-check"

Examples:

1. To check for CVEs in openssl
# bitbake -c cve_check openssl

2. To check for all recipes build for core-image-sato
# bitbake core-image-sato
# bitbake -k -c cve_check universe

Log files are created under tmp/log/cve/
...
libmicrohttpd_cve.json
libmicrohttpd-native_cve.json
libmnl_cve.json
libmnl-native_cve.json
libmodule-build-perl_cve.json
...

Example of log file:

{
"version": "1",
"package": [
{
"name": "zstd",
"layer": "meta",
"version": "1.5.5",
"products": [
{
"product": "zstandard",
"cvesInRecord": "Yes"
}
],
"issue": [
{
"id": "CVE-2019-11922",
"summary": "A race condition in the one-pass compression functions of Zstandard prior to version 1.3.8 could allow an attacker to write bytes out of bounds if an output buffer smaller than the recommended size was used.",
"scorev2": "6.8",
"scorev3": "8.1",
"vector": "NETWORK",
"vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P",
"status": "Patched",
"link": "https://nvd.nist.gov/vuln/detail/CVE-2019-11922"
},
...

==Q: How do I build a wic image? ==
'''A:''' Append "wic" to IMAGE_FSTYPES in your <code>conf/local.conf</code> :

Then, build the target image type as usual:
# bitbake <target-image-type>

The resulting images (*.wic) will be present in the "tmp/deploy/images" folder. E.g. if you build for core-image-minimal for qemzx86-64 you should find a file like: core-image-minimal-qemux86-64.rootfs.wic

How do I

2023-12-27T16:07:08Z

Simonew: Update fpr new cve check api

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How do I create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all *files* (not symlinks) in your download directory to the desired source mirror directory. Test by setting the variables below in <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
BB_NO_NETWORK = "1"

If you are building with <code>BB_NO_NETWORK</code> and using external layers that are not part of the base Yocto distribution, be aware that recipes which:

# Specify a Git repo as the source, and,
# Specify the revision to be built using a tag name

will cause your build to abort when Bitbake tries to run <code>git ls-remote</code> to resolve the tag name and is unable to access the network. So don't specify <code>SRC_URI</code> like this:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"</nowiki>

Instead, use:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"</nowiki>
SRCREV = "8885ced062131214448fae056ef453f094303805"

Before putting together your pre-mirror, this command can be used from
your top-level source directory to identify recipes that might be
problematic with <code>BB_NO_NETWORK</code> enabled:

find -name "*.inc" -o -name "*.bb" | xargs grep -li "git;tag="

== Q: How do I put Yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa := "5"

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

IMAGE_INSTALL_append = " hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

==Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? ==

'''A:''' You should read the [https://wiki.yoctoproject.org/wiki/Build_Performance Build Performance] wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

==Q: How do I get the networking to function on an Acer Aspire One n450 based netbook when using the meta-n450 BSP? ==

'''A:''' While the n450 BSP will boot on the Acer AO532h netbook, the BSP does not enable the Atheros AR5B95 Wireless and AR8132 fast ethernet adapters. The Linux Yocto 3.2 kernel has these drivers, but they are not enabled. All you have to do is to create a Config Fragment file with a .cfg extension in a new directory called 'linux-yocto' in the BSP recipes-kernel/linux directory. The new 'linux-yocto' directory will be at the same level as the linux-yocto_3.2.bbappend file. You will also need to add the following statement to the .bbappend file:

SRC_URI += "file://myconfig.cfg"

The recipes-kernel/linux/linux-yocto/myconfig.cfg needs to contain the following 2 lines:

CONFIG_ATH9K_PCI=y

CONFIG_ATL1C=y

==Q: How do I build the build appliance? ==
'''A:''' Update the MACHINE variable to "qemux86-64" or "qemux86" in your <code>conf/local.conf</code> :

Then, run this command:
# bitbake build-appliance-image

The resulting images (*.vmdk, *.vmx, *.vmxf) will be present in the "tmp/deploy/images" folder
ie:

# unzip Yocto_Build_Appliance.zip
# cd Yocto_Build_Appliance
# ls
Yocto_Build_Appliance.vmdk
Yocto_Build_Appliance.vmx
Yocto_Build_Appliance.vmxf

==Q: How do I build an image without GPLv3 Licensed packages ? ==
'''A:''' Add the line 'INCOMPATIBLE_LICENSE = "GPLv3"' in your <code>conf/local.conf</code> and ensure you have the GPLv2 replacement libraries. (Caveat emptor; they are not as well maintained.) From the Yocto Mega-Manual 2.4;

"If you use INCOMPATIBLE_LICENSE to exclude GPLv3 or set PREFERRED_VERSION to substitute a GPLv2 version of a GPLv3 recipe, then you must add the meta-gplv2 layer to your configuration."

Then, build the image:
# bitbake <image-name>

==Q: How do I ensure that I am using the latest upstream version of the package? ==
'''A:''' Add this line 'INHERIT += "distrodata"' in your <code>conf/local.conf</code> :

After that, run this command in the build directory:
# bitbake -c checkpkg <package>
Then, check the 'Version' and 'Upver' fields in the below listed file:
# gedit tmp/log/checkpkg.csv

If those versions are same, then we have the latest upstream version of package

==Q: How do I get a list of CVEs patched? ==
'''A:''' cve-check is available from 2.2 release (meta/recipes-core/meta/cve-update-nvd2-native.bb is used for acessing the new NVD database 2.0 API, meta/classes/cve-check.bbclass implements the check of recipes against CVEs).

To run it just inherit the class in conf/local.conf file:

# INHERIT += "cve-check"

Examples:

1. To check for CVEs in openssl
# bitbake -c cve_check openssl

2. To check for all recipes build for core-image-sato
# bitbake core-image-sato
# bitbake -k -c cve_check universe

Log files are created under tmp/log/cve/
...
libmicrohttpd_cve.json
libmicrohttpd-native_cve.json
libmnl_cve.json
libmnl-native_cve.json
libmodule-build-perl_cve.json
...

Example of log file:

{
"version": "1",
"package": [
{
"name": "zstd",
"layer": "meta",
"version": "1.5.5",
"products": [
{
"product": "zstandard",
"cvesInRecord": "Yes"
}
],
"issue": [
{
"id": "CVE-2019-11922",
"summary": "A race condition in the one-pass compression functions of Zstandard prior to version 1.3.8 could allow an attacker to write bytes out of bounds if an output buffer smaller than the recommended size was used.",
"scorev2": "6.8",
"scorev3": "8.1",
"vector": "NETWORK",
"vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P",
"status": "Patched",
"link": "https://nvd.nist.gov/vuln/detail/CVE-2019-11922"
},
...

==Q: How do I build a wic image? ==
'''A:''' Append "wic" to IMAGE_FSTYPES in your <code>conf/local.conf</code> :

Then, build the target image type as usual:
# bitbake <target-image-type>

The resulting images (*.wic) will be present in the "tmp/deploy/images" folder. E.g. if you build for core-image-minimal for qemzx86-64 you should find a file like: core-image-minimal-qemux86-64.rootfs.wic

How do I

2023-12-27T15:29:26Z

Simonew: /* Q: How do I build a wic image? */

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How do I create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all *files* (not symlinks) in your download directory to the desired source mirror directory. Test by setting the variables below in <code>conf/local.conf</code>:

SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
BB_NO_NETWORK = "1"

If you are building with <code>BB_NO_NETWORK</code> and using external layers that are not part of the base Yocto distribution, be aware that recipes which:

# Specify a Git repo as the source, and,
# Specify the revision to be built using a tag name

will cause your build to abort when Bitbake tries to run <code>git ls-remote</code> to resolve the tag name and is unable to access the network. So don't specify <code>SRC_URI</code> like this:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"</nowiki>

Instead, use:

<nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"</nowiki>
SRCREV = "8885ced062131214448fae056ef453f094303805"

Before putting together your pre-mirror, this command can be used from
your top-level source directory to identify recipes that might be
problematic with <code>BB_NO_NETWORK</code> enabled:

find -name "*.inc" -o -name "*.bb" | xargs grep -li "git;tag="

== Q: How do I put Yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa := "5"

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

IMAGE_INSTALL_append = " hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

==Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? ==

'''A:''' You should read the [https://wiki.yoctoproject.org/wiki/Build_Performance Build Performance] wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

==Q: How do I get the networking to function on an Acer Aspire One n450 based netbook when using the meta-n450 BSP? ==

'''A:''' While the n450 BSP will boot on the Acer AO532h netbook, the BSP does not enable the Atheros AR5B95 Wireless and AR8132 fast ethernet adapters. The Linux Yocto 3.2 kernel has these drivers, but they are not enabled. All you have to do is to create a Config Fragment file with a .cfg extension in a new directory called 'linux-yocto' in the BSP recipes-kernel/linux directory. The new 'linux-yocto' directory will be at the same level as the linux-yocto_3.2.bbappend file. You will also need to add the following statement to the .bbappend file:

SRC_URI += "file://myconfig.cfg"

The recipes-kernel/linux/linux-yocto/myconfig.cfg needs to contain the following 2 lines:

CONFIG_ATH9K_PCI=y

CONFIG_ATL1C=y

==Q: How do I build the build appliance? ==
'''A:''' Update the MACHINE variable to "qemux86-64" or "qemux86" in your <code>conf/local.conf</code> :

Then, run this command:
# bitbake build-appliance-image

The resulting images (*.vmdk, *.vmx, *.vmxf) will be present in the "tmp/deploy/images" folder
ie:

# unzip Yocto_Build_Appliance.zip
# cd Yocto_Build_Appliance
# ls
Yocto_Build_Appliance.vmdk
Yocto_Build_Appliance.vmx
Yocto_Build_Appliance.vmxf

==Q: How do I build an image without GPLv3 Licensed packages ? ==
'''A:''' Add the line 'INCOMPATIBLE_LICENSE = "GPLv3"' in your <code>conf/local.conf</code> and ensure you have the GPLv2 replacement libraries. (Caveat emptor; they are not as well maintained.) From the Yocto Mega-Manual 2.4;

"If you use INCOMPATIBLE_LICENSE to exclude GPLv3 or set PREFERRED_VERSION to substitute a GPLv2 version of a GPLv3 recipe, then you must add the meta-gplv2 layer to your configuration."

Then, build the image:
# bitbake <image-name>

==Q: How do I ensure that I am using the latest upstream version of the package? ==
'''A:''' Add this line 'INHERIT += "distrodata"' in your <code>conf/local.conf</code> :

After that, run this command in the build directory:
# bitbake -c checkpkg <package>
Then, check the 'Version' and 'Upver' fields in the below listed file:
# gedit tmp/log/checkpkg.csv

If those versions are same, then we have the latest upstream version of package

==Q: How do I get a list of CVEs patched? ==
'''A:''' cve-check tool is available from 2.2 release (poky/meta/recipes-devtools/cve-check-tool)

To run it just inherit the class in conf/local.conf file:

# INHERIT += "cve-check"

Source and run:
# bitbake -c cve_check openssl
# bitbake core-image-sato
# bitbake -k -c cve_check universe

Log files are created under
unzip/1_6.0-r5/cve/cve.log
gnutls/3.5.3-r0/cve/cve.log
glibc/2.24-r0/cve/cve.log
glibc-initial/2.24-r0/cve/cve.log
...

Example of log file:
PACKAGE NAME: perl
PACKAGE VERSION: 5.22.1
CVE: CVE-2016-1238
CVE STATUS: Patched
CVE SUMMARY: ....
....
CVSS v2 BASE SCORE: 7.2
VECTOR: LOCAL
MORE INFORMATION: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-1238

==Q: How do I build a wic image? ==
'''A:''' Append "wic" to IMAGE_FSTYPES in your <code>conf/local.conf</code> :

Then, build the target image type as usual:
# bitbake <target-image-type>

The resulting images (*.wic) will be present in the "tmp/deploy/images" folder. E.g. if you build for core-image-minimal for qemzx86-64 you should find a file like: core-image-minimal-qemux86-64.rootfs.wic

Ptest

2023-12-25T14:36:52Z

Simonew: /* General recipe preparations */

=Introduction=

Ptest (''package test'') is a concept for building, installing and running the test suites that are included in many upstream packages, and producing a consistent output format for the results.

=Adding ptest to your build=

To add package testing to your build, set the <code>DISTRO_FEATURES</code> and <code>EXTRA_IMAGE_FEATURES</code> variables in your <code>conf/local.conf</code> file, which is found in the Build Directory:

DISTRO_FEATURES:append = " ptest"
or
DISTRO_FEATURES_append = " ptest"
# Adding "ptest" to your DISTRO_FEATURES variable causes -ptest packages to be built.

EXTRA_IMAGE_FEATURES += "ptest-pkgs"
# Adding "ptest-pkgs" to IMAGE_FEATURES variable causes all -ptest packages corresponding with other packages installed in your image to be additionally installed.

As an alternative to the <code>ptest-pkgs</code> image feature, if you want to be more selective about which tests to include, you can install them individually e.g. to install the tests for e2fsprogs and zlib you would do something like this:

CORE_IMAGE_EXTRA_INSTALL += "e2fsprogs-ptest zlib-ptest"

This is of course just one way to add packages to an image, see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Customizing images] section of the Yocto Project development manual for more information.

All ptest files are installed in <code>/usr/lib/<package>/ptest</code>.

=Running ptest=

The "ptest-runner" package installs a "ptest-runner" which loops through all installed ptest test suites and runs them in sequence. You may therefore want to add "ptest-runner" to your image.

==ptest-runner Usage==

The usage for the ptest-runner is as follows:

Usage: ptest-runner [-d directory] [-l list] [-t timeout] [-h] [ptest1 ptest2 ...]

==Executing ptest-runner==

To execute a full ptest run you can do the following command line anywhere in the target:

$ ptest-runner

Remember to redirect to a file if you want to have a log

=Implementing ptest in a package recipe=

==What constitutes a ptest?==

A ptest must at minimum contain two things: <code>run-ptest</code> and the actual test.

<code>run-ptest</code> is a minimal shell script that ''starts'' the test suite. Note: It must not ''contain'' the test suite, only start it!

The test can be anything, from a simple shell script running a binary and checking its output to an elaborate system of test binaries and data files.

One major point of ptest is to consolidate the output format of all tests into a single common format. The format selected is the automake "simple test" format:

result: testname

Where "result" is one of PASS, FAIL or SKIP and "testname" can be any identifying string (the same format [http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests used by Automake].)

==General recipe preparations==

First, add <code>ptest</code> to the <code>inherit</code> line in the recipe.

If a test adds build-time or run-time dependencies to the package which are not there normally (such as requiring "make" to run the test suite), add those with a -ptest suffix, like this:

RDEPENDS:${PN}-ptest += "make"

==Building the test suite==

Few packages support cross-compiling their test suites, so this is something we typically have to add.

Many automake-based packages compile and run the test suite in a single command: "make check". This doesn't work when cross-compiling, since we need to build on host and run on target. So we need to split that into two targets: One for building the test and one for running it. Our build of automake comes with a [http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/automake/automake/buildtest.patch patch] which does this automatically, so packages using the plain "make check" arrangement from automake get this automatically.

Now add a do_compile_ptest function to build the test suite:

do_compile_ptest() {
oe_runmake buildtest-TESTS
}

If the package requires special configuration actions prior to compiling the test code, create a do_configure_ptest function to do that.

Note that buildtest-TESTS requires [https://www.gnu.org/software/automake/manual/html_node/Serial-Test-Harness.html serial-tests], but usually parallel tests are enabled by default.
In this case, you may have to modify the configure.ac script by adding serial-tests to AM_INIT_AUTOMAKE:

AM_INIT_AUTOMAKE([serial-tests])

Recursive targets may not work out of the box either, in that case also try adding the following into configure.ac:

AM_EXTRA_RECURSIVE_TARGETS([buildtest-TESTS])

==Installing the test suite==

The <code>ptest</code> class will automatically copy the required <code>run-ptest</code> file and run <code>make install-ptest</code> if there is such a target in the top-level <code>Makefile</code>. For packages where this is enough, you don't need to do anything else.

If you need to do something more than the automatic <code>make install-ptest</code>, create a <code>do_install_ptest</code> function within the recipe and put the required actions there. This function will be called after <code>make install-ptest</code> has completed.

==Recipes with ptest Enabled==

You can use the layer index search function to find out which recipes have ptest enabled by searching for recipes that inherit the <code>ptest</code> class:

http://layers.openembedded.org/layerindex/branch/master/recipes/?q=inherits%3Aptest

Specifically for OE-Core:

http://layers.openembedded.org/layerindex/branch/master/recipes/?q=inherits%3Aptest+layer%3Aopenembedded-core

Please consider when updating a recipe whether you can also incorporate a ptest package to it as well.

= QA =

For every Milestone of the release, QA team should execute pTest on real HW and compare the results with his previous corresponding execution (example 2.3 M2 should be compared with 2.3 M1 results) to track better all the releases ans execution an [[ Ptest/archive | archive ]] page was created to track all the executions and check what are the previous results available to compare.

* To check the process used to execute Ptest during QA cycles go to [[BSP_Test_Plan#pTest|pTest process]]

Poky

2023-12-23T20:50:44Z

Simonew: Fix link

See the https://docs.yoctoproject.org/ref-manual/terms.html#term-Poky page for information on this project.

Technical FAQ

2023-12-23T20:31:25Z

Simonew: Fix syntax

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
| '''NOTE:''' This is currently a draft. Not sure where this should end up but I've been gathering these based on my interactions with people on IRC and email over the years. - [[User:PaulEggleton|PaulEggleton]] ([[User talk:PaulEggleton|talk]]) 21:13, 27 June 2016 (PDT)
|}

== Basics ==

=== How do I figure out which version/codename/bitbake version matches up with which? ===

There is a table in the [http://wiki.yoctoproject.org/wiki/Releases Releases page] on the Yocto Project wiki.

=== How do I control what's in the final image? ===

Each image is defined by its own recipe, and that recipe specifies a list of packages that the image should contain. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Customising Images] within the Yocto Project development manual for further details.

Note: if you're doing anything more than basic experimentation / testing then you almost certainly should create your own image recipe rather than using one of the example images e.g. core-image-minimal - though you can certainly start by copying one of the example images. This way you have easier control over what goes into the image.

=== Where do I find build logs? ===

For the overall build, the output of bitbake gets logged to tmp/log/cooker/<machine>.

For each individual recipe, there is a "temp" directory under the work directory for the recipe that contains log.<taskname> and run.<taskname> files - the logs and the runfiles respectively. Within the build system this directory is pointed to by the T variable, so if you need to you can find it by using <code>bitbake -e</code>:

bitbake -e <recipename> | grep ^T=

=== How do I add a patch to a recipe? ===

There are two concerns - how the recipe can fetch the patch and how it can be applied. For fetching, patch files are usually placed in a subdirectory next to the recipe; by default this directory should be named "files" or the the recipe name without any class prefix or suffix (for example for both "xyz" and "xyz-native" the subdirectory would be "xyz"). A pointer to it then needs to be added to <code>SRC_URI</code> within the recipe, which usually takes the form <code>file://<patchname>.patch</code> - i.e. just the filename, no path. If more than one subdirectory needs to be stripped off the paths in the patch (i.e. you need more than the equivalent of the -p1 option to the patch command) then you can add <code>;striplevel=<number></code> to the end of the patch entry in SRC_URI (without any spaces).

As with any modification, if the patch you are applying is a customisation that you do not intend to send to be incorporated in the layer you are modifying, then instead of adding the patch to the recipe directly then you should consider applying it in a bbappend within your own custom layer. This makes things easier if you later want to update the layer in question and the recipe has been modified upstream - you avoid effectively forking the layer.

The <code>devtool</code> utility can help you modify the sources for a recipe and create a patch - basically <code>devtool modify</code>, edit the sources, commit the changes with <code>git commit</code>, then <code>devtool finish</code> (or <code>devtool update-recipe</code> in versions older than 2.2). Since <code>devtool modify</code> gives you a git tree to work with, you can of course use something like <code>git am</code> to apply existing patches this way. For more details see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#devtool-use-devtool-modify-to-enable-work-on-code-associated-with-an-existing-recipe Use devtool modify to Enable Work on Code Associated with an Existing Recipe] within the Yocto Project Development manual.

=== What does "native" mean? ===

The "native" suffix identifies recipes (and variants of recipes) that produce files intended for the build host, as opposed to the target machine. This is usually for tools that are needed during the build process (such as automake).

=== What does "nativesdk" mean? ===

The "nativesdk" prefix identifies recipes (and variants of recipes) that produce files intended for the host portion of the standard SDK, or for things which are constructed like an SDK such as buildtools-tarball. These are built for SDKMACHINE which may or may not be the same architecture as the build host.

=== I have two recipes and one needs to access files provided by another - how can that work? ===

Instead of providing direct access from a recipe to another's build tree (which wouldn't be practical with OpenEmbedded since the build tree (or "workdir") is temporary), we create a "sysroot" where files that are intended to be shared between recipes get copied. The sysroot is managed by the build system and you should not copy files in there directly - instead, you install files under ${D} as normal during do_install and then the build system will copy a subset of those to the sysroot. There is a seperate sysroot for each machine being built for. In a recipe you can get the path of the sysroot and various standard directories under it using the STAGING_* variables.

Often, for commonly-used build systems such as autotools and cmake you don't need to worry about these details - those systems and the environment that OpenEmbedded sets up for them will ensure that files get installed and picked up in the correct locations. However if the software your recipe is building has custom build scripts / makefiles and it takes shortcuts that don't account for cross-compilation or the use of a sysroot, then you will need to make appropriate adjustments.

=== How do I enable package management in the final image? ===

Add <code>package-management</code> to <code>IMAGE_FEATURES</code> (or <code>EXTRA_IMAGE_FEATURES</code>). You should then be able to use dnf/rpm, opkg, or apt-get/dpkg from the running system depending on the packaging format you have selected through PACKAGE_CLASSES. For more information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management Using Runtime Package Management] in the Yocto Project Development manual.

=== What do ?=, ??=, := etc. do within a recipe/config file? ===

See the [http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#basic-syntax Basic Syntax section of the BitBake manual] for details.

== Layers ==

See http://www.openembedded.org/Layers_FAQ

== Troubleshooting ==

=== I've created a recipe but it's not showing up in my image, what's going on? ===

Creating a recipe (or adding a layer to your configuration with a desired recipe in it) only makes it available to the build system, it doesn't change what goes into the image. For that, see [[#How do I control what's in the final image?|How do I control what's in the final image?]] above.

=== I set a variable but it doesn't seem to be having an effect, how do I fix this? ===

First, double-check that you haven't misspelled the variable name.

The main tool to help troubleshoot any variable-related issue is <code>bitbake -e</code> - this lists all the variables and the complete history of how each one has been set (use <code>bitbake -e <recipename></code> if you're dealing with issues in a variable value within a recipe as opposed to the global level). Usually it's best to pipe this through <code>less</code> so you can easily see the history - within less you can press / to search for the variable name. Often you will be dealing with the behaviour of a variable within the context of a specific recipe, so specify that recipe on the <code>bitbake -e</code> command line to get the variables as set within the context of the recipe rather than the global context.

If you're setting a variable in a bbappend, double-check that the bbappend is actually being applied - see the next question.

=== I've created a bbappend for a recipe but what I'm setting there isn't having any effect, how do I fix this? ===

Here are some things to check:

# Check if the layer the bbappend is in is listed in <code>bitbake-layers show-layers</code>. If it isn't, you need to edit your bblayers.conf and ensure the path to the layer is included in the BBLAYERS value
# Check that the bbappend is being picked up by running <code>bitbake-layers show-appends</code> - if your bbappend file isn't listed, it could be named incorrectly (such that it doesn't match the recipe name) or it may be that the BBFILES value in the conf/layer.conf for the layer containing the bbappend file doesn't include an expression that will match the bbappend files.
# If there are multiple versions of the recipe you have bbappended, it could be that the actual recipe being built is a different version than the one you have bbappended. <code>bitbake-layers show-recipes <recipename></code> will list all the versions, with the first one listed being the one that will be built. If this is the case there are several different solutions to this - (a) Rename your bbappend to match the version being built, (b) use a % wildcard in your bbappend so it will apply to any version, (c) set <code>PREFERRED_VERSION_<recipename></code> in the configuration to select a the version you want to be built.
# Finally, as with any other issue with setting variables, use <code>bitbake -e <recipename> | less</code> and search with <code>/</code> to see the history of how the variable has been set - you may find that the value you're trying set is being overridden.

=== I'm getting warnings that a recipe is tainted - what does this mean? ===

Usually this happens because you have used I used bitbake's <code>-f</code> or <code>-C</code> option to force a task to re-execute. The assumption is that if you forced a task, it is possible that a rebuild from scratch would not include whatever changes you made that necessitated forcing (e.g. if you modified the source in the work directory for the recipe and then ran <code>bitbake -c compile -f</code>). Generally, forcing a task should be reserved for situations where the build system has failed to detect a change you made rather than for everyday usage - if you're finding yourself needing to do it regularly then either there's a bug, you're doing something wrong, or perhaps you're using <code>-f</code> or <code>-C</code> when it's not really needed. Running <code>bitbake -c clean</code> on the recipe will get rid of the taint flag.

There is one other situation where we apply a taint, and that is <code>bitbake -c menuconfig</code> on the kernel (or some other kconfig-using recipe). In this case, the configuration has been saved into the work directory for the kernel, but that is temporary - any rebuild from scratch will use the default configuration, so it is a reminder that you need to take the configuration and apply it back to the metadata and then run <code>bitbake -c clean</code> on the kernel recipe.

=== I'm fetching from a git repository over ssh / http / https but it's not fetching properly, how do I fix this? ===

Bitbake expects the prefix of entries in SRC_URI to specify the fetcher to be used, not the actual protocol. Thus, instead of:

# This will NOT work
SRC_URI = "<nowiki>https://git.example.com/repository</nowiki>"

You should specify:

# This is better
SRC_URI = "<nowiki>git://git.example.com/repository;protocol=https</nowiki>"

The same applies for ssh and of course http.

=== I tried bitbake <some target package name> that I know exists and it told me that nothing PROVIDES this...? ===

There are two namespaces that bitbake concerns itself with - recipe names (a.k.a. build time targets) and package names (a.k.a. runtime targets). You can specify a build time target on the bitbake command line, but not a runtime target; you need to find the recipe that provides the package you are trying to build and build that instead (or simply add that package to your image and build the image). In current versions bitbake will at least tell you which recipes have matching or similar-sounding runtime provides (RPROVIDES) so that you'll usually get a hint on which recipe you need to build.

=== I've included a package in my image but files I expect to be there are missing, what's the issue? ===

Check the simple stuff: verify that the package is really in the image - look at the manifest file next to the image to ensure the package is listed. Also if you're flashing the image, double-check that you did indeed flash the right image and if there are multiple partitions / storage devices on your board or device that you're booting the one that you think you are.

Once you're sure of the above, it may be a matter of the package splitting - a lot of recipes split less commonly used components out to separate packages, so it's possible that the files you are looking for are in a different package. You can look at the recipe for this (look for PACKAGES and FILES statements) or assuming the recipe has been built, you can use <code>oe-pkgdata-util list-pkgs -p <recipename></code> and <code>oe-pkgdata-util list-pkg-files</code> to inspect the packages provided by the recipe and the files they contain. Once you find the right package you can add it to your image.

=== I'm required to set LIC_FILES_CHKSUM but the software I'm building doesn't have a license statement, what do I do? ===

Ideally, all software should come with some kind of license statement so that the terms of distribution are clearly stated (especially if its source code is made publicly available); if not a text file describing the license then at the very least a line or two in the accompanying documentation, README file or source header comments. Assuming there is a license statement somewhere but not in a form you can point to with LIC_FILES_CHKSUM as part of the source tree, you can point LIC_FILES_CHKSUM to one of the generic license files in ${COMMON_LICENSE_DIR} (meta/files/common-licenses/), or alternatively you can include a file containing the license statement in a "files" subdirectory next to the recipe (or subdirectory named the same as the recipe - see how such files are handled in other recipes), point to it in SRC_URI using file://, then add it to LIC_FILES_CHKSUM. It is worth noting however that LIC_FILES_CHKSUM is intended to give you a warning if upstream changes its license terms when you do an upgrade of the recipe, and by pointing it to this common license file that is part of the metadata, that mechanism will not function. You may wish to consider encouraging the upstream provider of the software your recipe is building to follow best practices and include a proper license statement, so that you can point to it in a future version. At minimum if you do use such workarounds, you will need to take extra care when upgrading the recipe in future in case the upstream provider changes the license terms.

If there really is no license stated at all anywhere for the software (and this is unfortunately not uncommon on github, for example) then you should really contact upstream - if there's no license, then technically you really shouldn't be distributing it until that's clarified with the original author(s).

=== I am getting a package QA error / warning when building a recipe, how do I solve it? ===

There are some general and specific recommendations in the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings QA Errors and Warnings] section of the Yocto Project Reference Manual.

=== I am getting "taskhash mismatch" errors, what does this mean and how do I fix it? ===

Bitbake parses the metadata (recipes, classes and configuration) repeatedly during its operation, and this error means that the result of parsing changed between one parse and the next. Two situations that can cause this:
# One of the parsed files changed in between e.g. you edited a recipe or performed a git operation (e.g. git checkout) during the build. '''Do not make changes to the metadata while a build is running.''' If you run the build again the error should not recur.
# Alternatively, there is something in the metadata that results in a variable expanding to a different value each time it is parsed. This is often something time-related e.g. a timestamp which is calculated every time an expression is expanded. The solution is to ensure the value is calculated once per build and then the expression expands to the same value for the duration of the build.

=== Building on a system with a GRSec kernel doesn't work well, is that supported? ===

No, grsec isn't really supported. The list of distros that are supported (tested) is in the Yocto mega manual for each release.
You can refer to the work-around given in this defect: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10885

=== Working around Firejail ===
For users of Parrot OS and other secured Linux distros, you will find that your bitbake fetch commands refuse to work, yet you can manually run wget and retrieve the packages with no problem. This is due to Poky creating links to all the tools it requires, in particular 'wget', 'ssh' and 'strings', using the links to these tools in the /usr/local/bin/ directory which all redirect to firejail. To fix the problem you can cd into <your Yocto install directory>/poky/build/tmp/hosttools directory and replace these links with ones redirecting to the actual executables under the /usr/bin directory.

== Dependencies ==

=== How do I find out why something is being built? ===

<code>bitbake -g <recipe></code> will produce some .dot files that allow you to see the dependency relationships - usually pn-depends.dot holds the answers although sometimes you may need to look at task-depends.dot if the dependency is only in the form of a task dependency. Note that these graphs are much too large for most graphviz visualisation tools to process, so you'll probably find it's easiest to view them with "less" or a text editor and search for the item you're looking for.

=== How do I find out why something is in my image? ===

Enable the buildhistory class and build the image again, and it will write out a depends.dot file containing the relationships between packages in the final image. If the package name isn't mentioned it is probably explicitly mentioned in IMAGE_INSTALL or being brought in via IMAGE_FEATURES.

See [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Maintaining Build Output Quality] in the Yocto Project Reference manual which covers how to enable buildhistory and the output it produces.

=== How do I view the .dot files produced by bitbake -g or buildhistory? ===

The size of some of these .dot graphs (particularly those produced by <code>bitbake -g</code>) is a little large for most viewers / processing tools, and unfortunately this isn't something that can be fixed - it's just the nature of the dependency relationships between targets and tasks within OpenEmbedded. Usually if you're just after answering a simple dependency question you can figure it out by viewing it with <code>less</code> and using its built-in search function (or alternatively your favourite text editor).

You can try [http://github.com/jrfonseca/xdot.py xdot] which will work well for some of the graphs, but the task graph produced by <code>bitbake -g</code> for something like an image in particular is likely to be too large to view within it.

=== Why are all of these -native items being built when my host distro has some of these available? ===

It's complicated. In some cases the software in question isn't widely packaged by common Linux distributions. In other cases we need to apply patches to the software, use a more up-to-date version than commonly packaged or build it with a particular configuration. In general it just helps us isolate ourselves from potential problems caused by differences in host Linux distributions. For the most part the time spent building the native tools that are definitely provided by the host distro are dwarfed by the time spent building things that definitely aren't provided, such as the C library for the target and the cross-compiling toolchain.

=== I disabled runtime package management and yet it still seems to be building rpm/opkg, why? ===

The build system always uses a package manager on the host to assemble images, because it is usually the best tool for this job. This is completely independent of whether the package manager is available in the target image - "package-management" being in IMAGE_FEATURES (possibly indirectly via EXTRA_IMAGE_FEATURES) controls whether the package manager is used at runtime i.e. whether it (and its associated package database) will be present in the target image.

=== Why is opkg-native / opkg-utils being built when I don't have ipk packaging enabled? ===

opkg-utils provides update-alternatives which is the default tool used to manage the alternatives system (for selecting between multiple providers of the same file, e.g. busybox and bash both provide /bin/sh).

=== Why is rpm-native being built when I don't have rpm packaging enabled? ===

rpm-native is needed for two things in the generic packaging code implemented in the package class:

# Debug symbol splitting - rpm-native provides the debugedit tool which this code uses
# Per-file dependencies - although this was originally just feeding into rpm when rpm was being used, it also now gets verified by QA checks regardless of which packaging backend is in use.

=== I see a recipe built, but building an image containing the corresponding package fails at do_rootfs because it can't find the package. How does this happen? ===

(For ipk, the error is "Couldn't find anything to satisfy '<package>'"; for rpm it is "<package> not found in the base feeds (<architecture list>)".)

Usually this is because the recipe claimed to provide the specified package (via PACKAGES or PACKAGES_DYNAMIC) but it wasn't actually produced, possibly because it ended up empty (since by default empty packages aren't produced), but the image or some other package still has a dependency that pulls in the specified package. If this is a recipe you are writing yourself the probable cause is your recipe isn't installing any files and thus the main package for the recipe is empty. Fix do_install (or what do_install is already running, e.g. make install) such that files are installed into the correct location such that they can then subsequently be packaged, and then all should be well.

In other situations the reference to the package in question is spurious and either it should be removed entirely or there's another package that should be used instead. For example, the avahi and dhcp recipes both have an empty main package since the client and server are split out into their own packages, and those are the ones you should be using instead (avahi-daemon, avahi-utils, dhcp-server, dhcp-client - there are other packages as well, please see [[#How_do_I_find_out_what_packages_are_produced_by_a_recipe.3F|How do I find out what packages are produced by a recipe?]].) You could argue that these recipes shouldn't claim to provide the main package, or they should have a main package that depends on all the other packages (as some other recipes do).

=== X11 and various other items are being built but I'm only building core-image-minimal that doesn't have X11 in it - why? ===

This is where it helps to understand the difference between build-time dependencies and runtime dependencies - often, a recipe will require things at build time (for example tools that help the build process, or to satisfy optional dependencies) that it doesn't necessarily need at runtime. The default configuration includes "<code>x11</code>" in <code>DISTRO_FEATURES</code>, and thus anything that can optionally support X11 will have its X11 support enabled; however when it comes to actually producing the image there won't be any X11 packages included as long as there are no hard dependencies and there aren't any X11 packages explicitly requested.

If you never intend to use X11, you can set your own <code>DISTRO_FEATURES</code> value that excludes <code>x11</code> (note lower case, as with all feature names) and then X11 support will be disabled at build time and these items won't even be built.

=== How do I avoid the kernel itself being pulled into my image when installing kernel modules? ===

By default, the kernel class sets a dependency on the kernel-base package (which kernel modules always depend on) onto kernel-image, which contains the actual kernel binary. If you don't want this, set the following either in your kernel recipe or at the configuration level:

RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""

Note: for older releases (pre-2.5) do this instead:

RDEPENDS_kernel-base = ""

== Misc ==

=== How do I remove a value from a list variable? ===

For variables that are expected to contain a space-separated list of items, BitBake supports a :remove operator to remove items from it. See [http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#removing-override-style-syntax Removal (override style syntax)] in the BitBake user manual.

'''NOTE:''' the :remove operation is final - you cannot "undo" it with other operations elsewhere, thus you should really only make use of it in your distro / local configuration and not in layers that you expect others to re-use for different purposes (and therefore they may need to undo your changes). An alternative way to effectively remove an item is to set the list outright to include all the items minus the one you want to remove.

=== How do I change how my recipe is built depending on what image I'm building? ===

The short answer is you cannot - the reason is that OpenEmbedded builds packages based on the overall configuration, and then the image only selects which of these packages should go into the final image. However, there are some solutions that do allow you to achieve the desired result:

# Have separate packages for the two different versions. This could take the form of different recipes or you could do it within the same recipe. The two packages do have to have different names however; this may create problems if you have other packages that depend on the package.
# Use a postprocessing function within the image(s) - within the image recipe, define a shell or python function that makes the desired changes to the files in the image and add a call to it to ROOTFS_POSTPROCESS_COMMAND within the image recipe. Note that this may not be appropriate if you have runtime package management enabled since the postprocessing will only happen at image creation time and not if the package is installed later on at runtime - you may need to use a postinstall script instead in this case.
# Use a postinstall script (pkg_postinst_<package> function) within the recipe. In order to work, the postinstall script will need to be able to determine what to do when it's run - this may not be practical depending on what you're trying to achieve.

=== Can I use a toolchain built by OE as the external toolchain? ===

In general, this is not recommended and not something that is tested or directly supported out of the box. If you are wanting to do this solely as a means of speeding up the build, it is strongly suggested that you use shared state instead.

There is a [http://layers.openembedded.org/layerindex/branch/master/layer/meta-sourcery/ meta-sourcery layer] available to enable support for the CodeSourcery toolchain, you may be able to use this as a template for bringing in an external toolchain however there are no guarantees.

=== Why can't I run bitbake as root? ===

If you try to run bitbake as root you may have noticed you get a sanity check failure that prevents the build from continuing. The reason we have this check is that it is very risky to run builds as root; if any build script mistakenly tries to install files to the root path (/) instead of where it is supposed to, you want it to fail immediately and not (in the worst case) overwrite files critical to your Linux system's operation e.g. under /bin or /etc. Thus, we do not support running the build as root. The only time root access is needed is (completely outside of a build) where the runqemu script uses sudo to set up TAP devices for networking.

=== When I run bitbake -c devshell it looks like it's running as root! How is that possible? ===

It's not running as the actual root user, it's just pretending for the benefit of programs that run under it (including your shell) that it is, via pseudo. This is important, because you normally want any owner/group/permission values that you set on files to be reflected in files that the recipe installs and packages and thus reflected in the final image - without this mechanism the actual build would have to run as root which would be very risky (see above). There are no actual elevated privileges through this mechanism however, so you need not be worried.

=== Why does OE use pseudo? Why not use fakeroot / fakechroot instead? ===

Splitting this up into two questions - we use pseudo (not to be confused with sudo!) because we want to be able to create images containing files have the correct permissions and ownership, e.g. files owned by root, without the user running the build system having to have that privilege. By using LD_PRELOAD to intercept function calls, pseudo creates an environment for programs running underneath it where it appears as if the running user has those privileges (and the results of any operations persist within the pseudo environment, i.e. you can write a file as root and it will appear to be owned by root while still running under pseudo). This allows us to run builds entirely as a normal user without needing extra privileges. Without pseudo we would require running the build system under sudo or as root - which would be ill-advised for things such as "make install" in case it happened to be broken and tried to write to / instead of somewhere under the work directory for the recipe; a broken recipe could easily end up destroying your system in that case.

To answer the second part, why we use pseudo instead of fakeroot / fakechroot, see [https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot WhyNotFakeroot on the pseudo wiki].

=== How do I find out what packages are produced by a recipe? ===

The Toaster web UI provides easy ways to query this.

In the 1.8 (fido) release and newer you can use the following command, assuming the recipe has already been built:

oe-pkgdata-util list-pkgs -p <recipename>

Alternatively you can look in the "packages-split" subdirectory under the work directory for the recipe - each package produced by the recipe will have a subdirectory under that. If you're not sure how to find the work directory you can run the following command:

bitbake -e <recipename> | grep ^WORKDIR=

Before a recipe gets built it is a bit trickier, since the system often doesn't know exactly which packages will be produced until do_package time; this is particularly true for recipes that package plugins or modules (e.g. kernel modules). You can get a reasonable idea though by looking at the value of PACKAGES (and PACKAGES_DYNAMIC for recipes that produce plugins).

=== How do I find out which package contains a particular file (or python module)? ===

oe-pkgdata-util has a find-path subcommand that will tell you exactly this. For example:

$ oe-pkgdata-util find-path /etc/network/interfaces
init-ifupdown: /etc/network/interfaces

Wildcards are allowed anywhere in the path (but you should enclose such expressions in quotes to avoid the shell itself attempting to expand the wildcard):

$ oe-pkgdata-util find-path "*/fstrim"
util-linux-bash-completion: /usr/share/bash-completion/completions/fstrim
util-linux-ptest: /usr/lib/util-linux/ptest/fstrim
util-linux-dbg: /sbin/.debug/fstrim
util-linux-fstrim: /sbin/fstrim

As a specific example of where this can be useful, our Python packaging is a bit more granular than most typical distributions, allowing you to tune the contents of your image to just what you need. However, that does mean you may have trouble figuring out which package provides a particular module. oe-pkgdata-util find-path can also be used for this. For example, to find the package containing the "shutil" module, run this:

$ oe-pkgdata-util find-path "*/shutil.*"
python3-shell: /usr/lib/python3.5/shutil.py
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.opt-2.pyc
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.opt-1.pyc
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.pyc

Thus the package you are looking for is python3-shell. (Note that you could use */shutil.py, but if the module you are looking for is written in C as some of them are, that won't match it.)

=== I have a local source tree I want to build instead of the upstream source a recipe normally fetches, how do I do that? ===

If it's for development purposes i.e. you have your own local source tree you want to work on and have built, then run:

devtool modify -n <recipename> path/to/sourcetree/

Once you are done you can use <code>devtool finish</code> or <code>devtool reset</code> (depending on the situation) to return to building the source specified in the recipe.

Alternatively if it's more permanent, use the <code>externalsrc</code> class - you can inherit this in the original recipe or a bbappend:

inherit externalsrc
EXTERNALSRC = "/path/to/sources"

If you're going to use it across a number of recipes you can inherit it globally at the configuration level (perhaps via an inc file that you include/require there):

INHERIT += "externalsrc"
EXTERNALSRC_pn-<recipename> = "/path/to/sources"

=== How do I specify the default shell? (e.g. bash instead of busybox) ===

It depends what you mean. As far as which provides /bin/sh, this is controlled through the alternatives system, and by default bash has a higher priority than busybox, so simply installing bash into your image will automatically have /bin/sh link to bash rather than busybox.

If you mean you want a user's login shell to be a specific shell, you'll need to modify /etc/passwd. One fairly easy way to achieve this is to use the extrausers class in your image recipe:

inherit extrausers
EXTRA_USERS_PARAMS = "usermod -s /bin/bash <username>; "

=== How do I get "full" versions of typical shell commands? ===

Most of the shell commands in our images are provided by busybox by default, and are very much simplified compared to what you would have on a typical Linux system in order to save space. If you need the full versions, most of them are built and packaged by the coreutils recipe (for disk and other typical utilities) and procps (for ps, etc). You may also want to install bash for more typical shell built-in commands. There is also a core-image-full-cmdline image if you want a base image that is already set up to provide a more typical Linux command-line experience. (Note: these will of course use up more disk space and memory.)

=== How do I allow a variable's value through from the external environment? ===

Add the variable's name to the BB_ENV_EXTRAWHITE ''in the external environment'' before running bitbake. Note that the oe-init-build-env script sets a default for this which you will want to preserve, so add to the default value rather than overwriting it.

Alternatively if you just want to get the external value of a variable from python code within the metadata, you can use the BB_ORIGENV variable which itself contains a datastore of the original environment. For example to get the value of the DISPLAY variable from the environment within a python function you would do this:

display = d.getVar("BB_ORIGENV", False).getVar("DISPLAY")

Note that you must specify "false" for the expand parameter when getting the BB_ORIGENV variable, because it's not a string and therefore cannot be expanded in the normal manner.

=== Why is bitbake showing "AUTOINC" in the version for some recipes? ===

Recipes where you see AUTOINC within the version in the console output during a build will be those that set <code>PV</code> to include <code>"${SRCPV}"</code> to get the SCM revision (e.g. the git hash) in the package version. In order to have the version increment properly, there needs to be a number in front of the revision which automatically increments each time the revision changes (assuming you have a PR server enabled), which is where AUTOINC comes in. During the build, AUTOINC is a stand-in for this auto-incrementing number, and later during <code>do_package</code> it gets replaced with the real number so that the packages produced at the end have the full version number.

=== Why are .so files in the -dev package instead of the main package for a recipe? ===

In standard Unix library packaging, non-versioned .so symlinks (e.g. /usr/lib/libgd.so) are intended for development purposes only. At runtime, binaries should be linked to the major-versioned .so file/symlink e.g. /usr/lib/libgd.so.3. This (theoretically) allows multiple major versions of the same library as well as binaries that depend upon each of them to coexist on the same system. If the library is versioned but you have a binary that links to the unversioned .so file, it has almost certainly been linked incorrectly.

Non-symlink .so files on the other hand are sometimes produced and are entirely legal - however these will be picked up in the -dev package in OpenEmbedded simply by virtue of their name, which is almost always not what you want. In this case you can do one of two things:

# Fix the build of the library so it gets versioned. This may not always be appropriate, especially not for things like plugins.
# Set FILES_${PN}-dev within the recipe so that it does not include ${FILES_SOLIBSDEV}. If the software the recipe is building also produces symlink .so files you'll need to set FILES_${PN}-dev such that those do still get packaged in the -dev package though, or you'll get a package QA warning.

=== Can I disable shared state? ===

You cannot, no. Shared state (sstate) is an intrinsic part of staging files into the sysroot. It is possible to construct a recipe that bypasses sstate for some tasks (the kernel does this), however this is quite difficult and if not done properly will lead to many other problems.

Almost always when you are having a problem with shared state the issue is either (a) you're adding/changing files in the sysroot directly (i.e. outside sstate control), or (b) what is being placed into the sysroot isn't relocatable due to hardcoded paths. The solution for (a) is do not do that - files should always be installed under <code>${D}</code> within <code>do_install</code> and then a subset of those are staged into the sysroot automatically. For (b) you need to fix or adapt the hardcoded path(s) - if the program reads (or can be made to read) each path from an environment variable, then you can use the <code>create_wrapper</code> utility function to create a wrapper script that will set the path appropriately. Run <code>git grep create_wrapper</code> in the <code>meta</code> subdirectory to see examples.

=== Files I installed into /opt or some other path never make it into the sysroot but I need them - how do I fix this? ===

OpenEmbedded only stages a subset of files that are installed into <code>${D}</code> by <code>do_install</code> so that the sysroot doesn't fill up with unneeded files. You have two choices in this situation:
# install the files into a more standard location which is part of the subset, or
# adjust the subset to include the paths you are installing to.
Usually option 1 is recommended. If you really do need to adjust the subset, you can append the path (more specifically, the part below <code>${D}</code>) to <code>SYSROOT_DIRS</code> within your recipe. For example:

SYSROOT_DIRS += "/opt"

=== I have some software which needs to build a binary that it then runs as part of its own build process, how do I make this work? ===

Whilst it is possible to do this within a single recipe building for the target, it is tricky to do so because in that context everything is set up for cross-compiling for the target, and you would have to undo all of that to build host tools. The standard and much easier way of handling this is to create a native variant of the recipe using BBCLASSEXTEND and have your host tools built within that, and then have the target variant depend on the native variant. For example, assume your recipe were called xyz (xyz_1.1.bb), then you would include something like this in the recipe:

DEPENDS:append_class-target = " xyz-native"

...

BBCLASSEXTEND += "native"

The host tools will then be built and installed into the sysroot in the native variant ready for when the target variant starts building. If the software you are building didn't intend for those tools to be installed outside of the build tree then you may need to patch the build process (e.g. the makefile) in order to install them and possibly also for the target side to find them in the sysroot. Additionally, for performance since you only need the tools in the native variant, you may also choose to disable building everything except those tools there - e.g. by using _native overrides for variables such as EXTRA_OECONF or functions such as do_configure.

=== How do I fetch from two git repositories in the same recipe? ===

By default, sources fetched from git within a recipe are unpacked into ${WORKDIR}/git, however that only works for a single repository. If you want to fetch from more than one, you need to change the path each repository is unpacked to. This is easy to do, just add <code>;destsuffix=<subdir></code> to the end of each URL in SRC_URI (replacing <code><subdir></code> with the name of the subdirectory). You may then need to change S to match whichever of these you want to be considered the root of the source tree - or alternatively you can specify destsuffix such that repositories beyond the first go into a subdirectory under the default "git" subdirectory. For example, from the gst-libav recipe:

...
SRC_URI = " \
git://anongit.freedesktop.org/gstreamer/gst-libav;branch=1.8;name=base \
git://anongit.freedesktop.org/gstreamer/common;destsuffix=git/common;name=common \
...
"
...
S = "${WORKDIR}/git"
...

(Here we're using the default of "git" for the first repository, so we don't need to specify <code>destsuffix</code> for the first URL.)

=== I'm building a native recipe and I notice that the install path has the full path to the root directory repeated - why? ===

It does look a little odd, but the reason for doing this is that native targets are meant to run on the system they're built on and run in the location they're installed to. This means they install to a destination of "/" and PREFIX is inside the native sysroot directory. We install them to a DESTDIR to allow us to manipulate them before they then get moved to a final DESTDIR of "/".

Most Makefiles handle this correctly by doing:

DESTDIR ?= ""
prefix ?= "/usr"
bindir ?= "$(prefix)/bin"

and then, importantly, install in the form:

install -d $(DESTDIR)$(bindir)

so both prefix and DESTDIR are used. Whilst this is a convention, its a widely adopted and followed one. You can call into a custom makefile and set the variables manually if the makefile doesn't follow the convention.

=== How do I generate static libraries? ===

Its possible you have conf/distro/include/no-static-libs.inc included in your build - poky does this by default. The include list at the top of the bitbake -e output will tell you for certain.

If so, you can remove that or set:

DISABLE_STATIC = ""

as it would currently be set to this if that include file is included:

DISABLE_STATIC = " --disable-static"

Poky disables building static libraries by default as for the most part they're a waste of space/time.

=== Can I conditionally inherit a class in a recipe? ===

Yes, you can. What makes this possible is that the <code>inherit</code> keyword will not complain if what comes after it expands to being empty, so you can use in-line python to do something like this:

<pre><nowiki>
inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perlnative', '', d)}
</nowiki></pre>

The above example will inherit the <code>perlnative</code> class if "scripting" is in the value of the <code>PACKAGECONFIG</code> variable, otherwise it will do nothing.

You could of course put this into a variable if you prefer:

<pre><nowiki>
SOMEVAR = "${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perlnative', '', d)}"
inherit ${SOMEVAR}
</nowiki></pre>

=== How do I collect the source revisions fetched by each recipe? ===

If you have recipes where <code>SRCREV = "${AUTOREV}"</code> then you won't necessarily know exactly which revisions were built after the fact - it will be whatever was current at the time. You also might alternatively just want to get all of the revisions. Either way, to do this, enable buildhistory by setting the following in your local.conf:

<pre><nowiki>
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
</nowiki></pre>

(The last line is not required with version 2.5 and onwards as it is the default, but will do no harm.)

Once you have enabled buildhistory, you then need to build your image again so that buildhistory has a chance to record history data for it. Following that you can run <code>buildhistory-collect-srcrevs</code> (with <code>-a</code> if you want to see all revisions, not just the ones where AUTOREV was used) and it will output the revisions in a form you can use in a .inc file that you can <code>require</code> from your configuration if you want to fix the build to those revisions.

For more information see the [https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#maintaining-build-output-quality Maintaining Build Output Quality] section of the Yocto Project Development manual, which covers the buildhistory class in detail.

=== How do I do an offline build with recipes that have <code>SRCREV = "${AUTOREV}"</code> set? ===

If you set <code>BB_NO_NETWORK = "1"</code> and you have recipes that have <code>SRCREV = "${AUTOREV}"</code>, you will get an error because the build system will try to check the latest revision on startup and be immediately blocked by <code>BB_NO_NETWORK</code>. There are two ways to handle this:

A) See the previous question "How do I collect the source revisions fetched by each recipe?" and use the output generated by <code>buildhistory-collect-srcrevs</code> as a .inc file in your configuration in order to fix the revisions at the ones which were most recently built.

or

B) Set <code>BB_SRCREV_POLICY = "cache"</code> in your configuration. This will use the last cached revision. (The disadvantage of this method is that it is a little more difficult to preserve or share with others the fixed revisions.)

Note that in either case if you later want to build the latest version again, you will of course need to undo the configuration changes.

=== Is it possible to append a bbclass file (like bbappends do for recipes)? ===

No, see the next question for details.

=== How do I override a bbclass file? ===

This is tricky - bbclass files are found via BBPATH, which is added to by each layer.conf either by prepending or appending. Assuming you are putting your bbclass in a custom layer, you will probably want to have your layer's layer.conf prepend to BBPATH, but then you will also need to make sure that your layer does not appear before any other layer that is also prepending and overriding the same class.

Another alternative is to have an additional class which makes the appropriate changes to the environment, and then you will need to inherit that class after (and in the same manner as) the original class. This is slightly cleaner but can be annoying to enable particularly if the class is inherited by a number of recipes, and won't work if you want to alter the behaviour of a class inherited by recipes you don't control. (If you want a class to be inherited for all images (i.e. all recipes inheriting the <code>image</code> class) you can inject additional classes by setting IMAGE_CLASSES; similarly for the kernel there is KERNEL_CLASSES).

Ultimately, overriding bbclass files is not good practice long term - you are opening yourself up to maintenance issues when the original class changes, and the override is fragile as hinted above. The best solution is to try to get whatever changes you need into the original class; this does of course require additional work and time though.

=== There's a bbappend in a layer I'm using that defines a <code>do_something:append()</code> and I want to append to that function also, how do I do this? ===

Simply create a bbappend in your layer and define your own <code>do_something:append()</code>, and your commands will be executed ''as well as'' those of the other bbappend.

You might assume that defining <code>do_something:append()</code> will overwrite any previously defined <code>do_something:append()</code>, as would be the case with <code>do_something()</code> in the same situation, but that is not the case - the key is that <code>:append</code> (and <code>:prepend</code>, <code>:remove</code>, etc.) are ''operators'' and they will be applied in sequence, where that sequence is the order in which they are parsed (which for bbappends will be in ascending layer priority order).

Technical FAQ

2023-12-23T20:30:44Z

Simonew: Fix syntax

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
| '''NOTE:''' This is currently a draft. Not sure where this should end up but I've been gathering these based on my interactions with people on IRC and email over the years. - [[User:PaulEggleton|PaulEggleton]] ([[User talk:PaulEggleton|talk]]) 21:13, 27 June 2016 (PDT)
|}

== Basics ==

=== How do I figure out which version/codename/bitbake version matches up with which? ===

There is a table in the [http://wiki.yoctoproject.org/wiki/Releases Releases page] on the Yocto Project wiki.

=== How do I control what's in the final image? ===

Each image is defined by its own recipe, and that recipe specifies a list of packages that the image should contain. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Customising Images] within the Yocto Project development manual for further details.

Note: if you're doing anything more than basic experimentation / testing then you almost certainly should create your own image recipe rather than using one of the example images e.g. core-image-minimal - though you can certainly start by copying one of the example images. This way you have easier control over what goes into the image.

=== Where do I find build logs? ===

For the overall build, the output of bitbake gets logged to tmp/log/cooker/<machine>.

For each individual recipe, there is a "temp" directory under the work directory for the recipe that contains log.<taskname> and run.<taskname> files - the logs and the runfiles respectively. Within the build system this directory is pointed to by the T variable, so if you need to you can find it by using <code>bitbake -e</code>:

bitbake -e <recipename> | grep ^T=

=== How do I add a patch to a recipe? ===

There are two concerns - how the recipe can fetch the patch and how it can be applied. For fetching, patch files are usually placed in a subdirectory next to the recipe; by default this directory should be named "files" or the the recipe name without any class prefix or suffix (for example for both "xyz" and "xyz-native" the subdirectory would be "xyz"). A pointer to it then needs to be added to <code>SRC_URI</code> within the recipe, which usually takes the form <code>file://<patchname>.patch</code> - i.e. just the filename, no path. If more than one subdirectory needs to be stripped off the paths in the patch (i.e. you need more than the equivalent of the -p1 option to the patch command) then you can add <code>;striplevel=<number></code> to the end of the patch entry in SRC_URI (without any spaces).

As with any modification, if the patch you are applying is a customisation that you do not intend to send to be incorporated in the layer you are modifying, then instead of adding the patch to the recipe directly then you should consider applying it in a bbappend within your own custom layer. This makes things easier if you later want to update the layer in question and the recipe has been modified upstream - you avoid effectively forking the layer.

The <code>devtool</code> utility can help you modify the sources for a recipe and create a patch - basically <code>devtool modify</code>, edit the sources, commit the changes with <code>git commit</code>, then <code>devtool finish</code> (or <code>devtool update-recipe</code> in versions older than 2.2). Since <code>devtool modify</code> gives you a git tree to work with, you can of course use something like <code>git am</code> to apply existing patches this way. For more details see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#devtool-use-devtool-modify-to-enable-work-on-code-associated-with-an-existing-recipe Use devtool modify to Enable Work on Code Associated with an Existing Recipe] within the Yocto Project Development manual.

=== What does "native" mean? ===

The "native" suffix identifies recipes (and variants of recipes) that produce files intended for the build host, as opposed to the target machine. This is usually for tools that are needed during the build process (such as automake).

=== What does "nativesdk" mean? ===

The "nativesdk" prefix identifies recipes (and variants of recipes) that produce files intended for the host portion of the standard SDK, or for things which are constructed like an SDK such as buildtools-tarball. These are built for SDKMACHINE which may or may not be the same architecture as the build host.

=== I have two recipes and one needs to access files provided by another - how can that work? ===

Instead of providing direct access from a recipe to another's build tree (which wouldn't be practical with OpenEmbedded since the build tree (or "workdir") is temporary), we create a "sysroot" where files that are intended to be shared between recipes get copied. The sysroot is managed by the build system and you should not copy files in there directly - instead, you install files under ${D} as normal during do_install and then the build system will copy a subset of those to the sysroot. There is a seperate sysroot for each machine being built for. In a recipe you can get the path of the sysroot and various standard directories under it using the STAGING_* variables.

Often, for commonly-used build systems such as autotools and cmake you don't need to worry about these details - those systems and the environment that OpenEmbedded sets up for them will ensure that files get installed and picked up in the correct locations. However if the software your recipe is building has custom build scripts / makefiles and it takes shortcuts that don't account for cross-compilation or the use of a sysroot, then you will need to make appropriate adjustments.

=== How do I enable package management in the final image? ===

Add <code>package-management</code> to <code>IMAGE_FEATURES</code> (or <code>EXTRA_IMAGE_FEATURES</code>). You should then be able to use dnf/rpm, opkg, or apt-get/dpkg from the running system depending on the packaging format you have selected through PACKAGE_CLASSES. For more information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management Using Runtime Package Management] in the Yocto Project Development manual.

=== What do ?=, ??=, := etc. do within a recipe/config file? ===

See the [http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#basic-syntax Basic Syntax section of the BitBake manual] for details.

== Layers ==

See http://www.openembedded.org/Layers_FAQ

== Troubleshooting ==

=== I've created a recipe but it's not showing up in my image, what's going on? ===

Creating a recipe (or adding a layer to your configuration with a desired recipe in it) only makes it available to the build system, it doesn't change what goes into the image. For that, see [[#How do I control what's in the final image?|How do I control what's in the final image?]] above.

=== I set a variable but it doesn't seem to be having an effect, how do I fix this? ===

First, double-check that you haven't misspelled the variable name.

The main tool to help troubleshoot any variable-related issue is <code>bitbake -e</code> - this lists all the variables and the complete history of how each one has been set (use <code>bitbake -e <recipename></code> if you're dealing with issues in a variable value within a recipe as opposed to the global level). Usually it's best to pipe this through <code>less</code> so you can easily see the history - within less you can press / to search for the variable name. Often you will be dealing with the behaviour of a variable within the context of a specific recipe, so specify that recipe on the <code>bitbake -e</code> command line to get the variables as set within the context of the recipe rather than the global context.

If you're setting a variable in a bbappend, double-check that the bbappend is actually being applied - see the next question.

=== I've created a bbappend for a recipe but what I'm setting there isn't having any effect, how do I fix this? ===

Here are some things to check:

# Check if the layer the bbappend is in is listed in <code>bitbake-layers show-layers</code>. If it isn't, you need to edit your bblayers.conf and ensure the path to the layer is included in the BBLAYERS value
# Check that the bbappend is being picked up by running <code>bitbake-layers show-appends</code> - if your bbappend file isn't listed, it could be named incorrectly (such that it doesn't match the recipe name) or it may be that the BBFILES value in the conf/layer.conf for the layer containing the bbappend file doesn't include an expression that will match the bbappend files.
# If there are multiple versions of the recipe you have bbappended, it could be that the actual recipe being built is a different version than the one you have bbappended. <code>bitbake-layers show-recipes <recipename></code> will list all the versions, with the first one listed being the one that will be built. If this is the case there are several different solutions to this - (a) Rename your bbappend to match the version being built, (b) use a % wildcard in your bbappend so it will apply to any version, (c) set <code>PREFERRED_VERSION_<recipename></code> in the configuration to select a the version you want to be built.
# Finally, as with any other issue with setting variables, use <code>bitbake -e <recipename> | less</code> and search with <code>/</code> to see the history of how the variable has been set - you may find that the value you're trying set is being overridden.

=== I'm getting warnings that a recipe is tainted - what does this mean? ===

Usually this happens because you have used I used bitbake's <code>-f</code> or <code>-C</code> option to force a task to re-execute. The assumption is that if you forced a task, it is possible that a rebuild from scratch would not include whatever changes you made that necessitated forcing (e.g. if you modified the source in the work directory for the recipe and then ran <code>bitbake -c compile -f</code>). Generally, forcing a task should be reserved for situations where the build system has failed to detect a change you made rather than for everyday usage - if you're finding yourself needing to do it regularly then either there's a bug, you're doing something wrong, or perhaps you're using <code>-f</code> or <code>-C</code> when it's not really needed. Running <code>bitbake -c clean</code> on the recipe will get rid of the taint flag.

There is one other situation where we apply a taint, and that is <code>bitbake -c menuconfig</code> on the kernel (or some other kconfig-using recipe). In this case, the configuration has been saved into the work directory for the kernel, but that is temporary - any rebuild from scratch will use the default configuration, so it is a reminder that you need to take the configuration and apply it back to the metadata and then run <code>bitbake -c clean</code> on the kernel recipe.

=== I'm fetching from a git repository over ssh / http / https but it's not fetching properly, how do I fix this? ===

Bitbake expects the prefix of entries in SRC_URI to specify the fetcher to be used, not the actual protocol. Thus, instead of:

# This will NOT work
SRC_URI = "<nowiki>https://git.example.com/repository</nowiki>"

You should specify:

# This is better
SRC_URI = "<nowiki>git://git.example.com/repository;protocol=https</nowiki>"

The same applies for ssh and of course http.

=== I tried bitbake <some target package name> that I know exists and it told me that nothing PROVIDES this...? ===

There are two namespaces that bitbake concerns itself with - recipe names (a.k.a. build time targets) and package names (a.k.a. runtime targets). You can specify a build time target on the bitbake command line, but not a runtime target; you need to find the recipe that provides the package you are trying to build and build that instead (or simply add that package to your image and build the image). In current versions bitbake will at least tell you which recipes have matching or similar-sounding runtime provides (RPROVIDES) so that you'll usually get a hint on which recipe you need to build.

=== I've included a package in my image but files I expect to be there are missing, what's the issue? ===

Check the simple stuff: verify that the package is really in the image - look at the manifest file next to the image to ensure the package is listed. Also if you're flashing the image, double-check that you did indeed flash the right image and if there are multiple partitions / storage devices on your board or device that you're booting the one that you think you are.

Once you're sure of the above, it may be a matter of the package splitting - a lot of recipes split less commonly used components out to separate packages, so it's possible that the files you are looking for are in a different package. You can look at the recipe for this (look for PACKAGES and FILES statements) or assuming the recipe has been built, you can use <code>oe-pkgdata-util list-pkgs -p <recipename></code> and <code>oe-pkgdata-util list-pkg-files</code> to inspect the packages provided by the recipe and the files they contain. Once you find the right package you can add it to your image.

=== I'm required to set LIC_FILES_CHKSUM but the software I'm building doesn't have a license statement, what do I do? ===

Ideally, all software should come with some kind of license statement so that the terms of distribution are clearly stated (especially if its source code is made publicly available); if not a text file describing the license then at the very least a line or two in the accompanying documentation, README file or source header comments. Assuming there is a license statement somewhere but not in a form you can point to with LIC_FILES_CHKSUM as part of the source tree, you can point LIC_FILES_CHKSUM to one of the generic license files in ${COMMON_LICENSE_DIR} (meta/files/common-licenses/), or alternatively you can include a file containing the license statement in a "files" subdirectory next to the recipe (or subdirectory named the same as the recipe - see how such files are handled in other recipes), point to it in SRC_URI using file://, then add it to LIC_FILES_CHKSUM. It is worth noting however that LIC_FILES_CHKSUM is intended to give you a warning if upstream changes its license terms when you do an upgrade of the recipe, and by pointing it to this common license file that is part of the metadata, that mechanism will not function. You may wish to consider encouraging the upstream provider of the software your recipe is building to follow best practices and include a proper license statement, so that you can point to it in a future version. At minimum if you do use such workarounds, you will need to take extra care when upgrading the recipe in future in case the upstream provider changes the license terms.

If there really is no license stated at all anywhere for the software (and this is unfortunately not uncommon on github, for example) then you should really contact upstream - if there's no license, then technically you really shouldn't be distributing it until that's clarified with the original author(s).

=== I am getting a package QA error / warning when building a recipe, how do I solve it? ===

There are some general and specific recommendations in the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings QA Errors and Warnings] section of the Yocto Project Reference Manual.

=== I am getting "taskhash mismatch" errors, what does this mean and how do I fix it? ===

Bitbake parses the metadata (recipes, classes and configuration) repeatedly during its operation, and this error means that the result of parsing changed between one parse and the next. Two situations that can cause this:
# One of the parsed files changed in between e.g. you edited a recipe or performed a git operation (e.g. git checkout) during the build. '''Do not make changes to the metadata while a build is running.''' If you run the build again the error should not recur.
# Alternatively, there is something in the metadata that results in a variable expanding to a different value each time it is parsed. This is often something time-related e.g. a timestamp which is calculated every time an expression is expanded. The solution is to ensure the value is calculated once per build and then the expression expands to the same value for the duration of the build.

=== Building on a system with a GRSec kernel doesn't work well, is that supported? ===

No, grsec isn't really supported. The list of distros that are supported (tested) is in the Yocto mega manual for each release.
You can refer to the work-around given in this defect: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10885

=== Working around Firejail ===
For users of Parrot OS and other secured Linux distros, you will find that your bitbake fetch commands refuse to work, yet you can manually run wget and retrieve the packages with no problem. This is due to Poky creating links to all the tools it requires, in particular 'wget', 'ssh' and 'strings', using the links to these tools in the /usr/local/bin/ directory which all redirect to firejail. To fix the problem you can cd into <your Yocto install directory>/poky/build/tmp/hosttools directory and replace these links with ones redirecting to the actual executables under the /usr/bin directory.

== Dependencies ==

=== How do I find out why something is being built? ===

<code>bitbake -g <recipe></code> will produce some .dot files that allow you to see the dependency relationships - usually pn-depends.dot holds the answers although sometimes you may need to look at task-depends.dot if the dependency is only in the form of a task dependency. Note that these graphs are much too large for most graphviz visualisation tools to process, so you'll probably find it's easiest to view them with "less" or a text editor and search for the item you're looking for.

=== How do I find out why something is in my image? ===

Enable the buildhistory class and build the image again, and it will write out a depends.dot file containing the relationships between packages in the final image. If the package name isn't mentioned it is probably explicitly mentioned in IMAGE_INSTALL or being brought in via IMAGE_FEATURES.

See [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Maintaining Build Output Quality] in the Yocto Project Reference manual which covers how to enable buildhistory and the output it produces.

=== How do I view the .dot files produced by bitbake -g or buildhistory? ===

The size of some of these .dot graphs (particularly those produced by <code>bitbake -g</code>) is a little large for most viewers / processing tools, and unfortunately this isn't something that can be fixed - it's just the nature of the dependency relationships between targets and tasks within OpenEmbedded. Usually if you're just after answering a simple dependency question you can figure it out by viewing it with <code>less</code> and using its built-in search function (or alternatively your favourite text editor).

You can try [http://github.com/jrfonseca/xdot.py xdot] which will work well for some of the graphs, but the task graph produced by <code>bitbake -g</code> for something like an image in particular is likely to be too large to view within it.

=== Why are all of these -native items being built when my host distro has some of these available? ===

It's complicated. In some cases the software in question isn't widely packaged by common Linux distributions. In other cases we need to apply patches to the software, use a more up-to-date version than commonly packaged or build it with a particular configuration. In general it just helps us isolate ourselves from potential problems caused by differences in host Linux distributions. For the most part the time spent building the native tools that are definitely provided by the host distro are dwarfed by the time spent building things that definitely aren't provided, such as the C library for the target and the cross-compiling toolchain.

=== I disabled runtime package management and yet it still seems to be building rpm/opkg, why? ===

The build system always uses a package manager on the host to assemble images, because it is usually the best tool for this job. This is completely independent of whether the package manager is available in the target image - "package-management" being in IMAGE_FEATURES (possibly indirectly via EXTRA_IMAGE_FEATURES) controls whether the package manager is used at runtime i.e. whether it (and its associated package database) will be present in the target image.

=== Why is opkg-native / opkg-utils being built when I don't have ipk packaging enabled? ===

opkg-utils provides update-alternatives which is the default tool used to manage the alternatives system (for selecting between multiple providers of the same file, e.g. busybox and bash both provide /bin/sh).

=== Why is rpm-native being built when I don't have rpm packaging enabled? ===

rpm-native is needed for two things in the generic packaging code implemented in the package class:

# Debug symbol splitting - rpm-native provides the debugedit tool which this code uses
# Per-file dependencies - although this was originally just feeding into rpm when rpm was being used, it also now gets verified by QA checks regardless of which packaging backend is in use.

=== I see a recipe built, but building an image containing the corresponding package fails at do_rootfs because it can't find the package. How does this happen? ===

(For ipk, the error is "Couldn't find anything to satisfy '<package>'"; for rpm it is "<package> not found in the base feeds (<architecture list>)".)

Usually this is because the recipe claimed to provide the specified package (via PACKAGES or PACKAGES_DYNAMIC) but it wasn't actually produced, possibly because it ended up empty (since by default empty packages aren't produced), but the image or some other package still has a dependency that pulls in the specified package. If this is a recipe you are writing yourself the probable cause is your recipe isn't installing any files and thus the main package for the recipe is empty. Fix do_install (or what do_install is already running, e.g. make install) such that files are installed into the correct location such that they can then subsequently be packaged, and then all should be well.

In other situations the reference to the package in question is spurious and either it should be removed entirely or there's another package that should be used instead. For example, the avahi and dhcp recipes both have an empty main package since the client and server are split out into their own packages, and those are the ones you should be using instead (avahi-daemon, avahi-utils, dhcp-server, dhcp-client - there are other packages as well, please see [[#How_do_I_find_out_what_packages_are_produced_by_a_recipe.3F|How do I find out what packages are produced by a recipe?]].) You could argue that these recipes shouldn't claim to provide the main package, or they should have a main package that depends on all the other packages (as some other recipes do).

=== X11 and various other items are being built but I'm only building core-image-minimal that doesn't have X11 in it - why? ===

This is where it helps to understand the difference between build-time dependencies and runtime dependencies - often, a recipe will require things at build time (for example tools that help the build process, or to satisfy optional dependencies) that it doesn't necessarily need at runtime. The default configuration includes "<code>x11</code>" in <code>DISTRO_FEATURES</code>, and thus anything that can optionally support X11 will have its X11 support enabled; however when it comes to actually producing the image there won't be any X11 packages included as long as there are no hard dependencies and there aren't any X11 packages explicitly requested.

If you never intend to use X11, you can set your own <code>DISTRO_FEATURES</code> value that excludes <code>x11</code> (note lower case, as with all feature names) and then X11 support will be disabled at build time and these items won't even be built.

=== How do I avoid the kernel itself being pulled into my image when installing kernel modules? ===

By default, the kernel class sets a dependency on the kernel-base package (which kernel modules always depend on) onto kernel-image, which contains the actual kernel binary. If you don't want this, set the following either in your kernel recipe or at the configuration level:

RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""

Note: for older releases (pre-2.5) do this instead:

RDEPENDS_kernel-base = ""

== Misc ==

=== How do I remove a value from a list variable? ===

For variables that are expected to contain a space-separated list of items, BitBake supports a _remove operator to remove items from it. See [http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#removing-override-style-syntax Removal (override style syntax)] in the BitBake user manual.

'''NOTE:''' the _remove operation is final - you cannot "undo" it with other operations elsewhere, thus you should really only make use of it in your distro / local configuration and not in layers that you expect others to re-use for different purposes (and therefore they may need to undo your changes). An alternative way to effectively remove an item is to set the list outright to include all the items minus the one you want to remove.

=== How do I change how my recipe is built depending on what image I'm building? ===

The short answer is you cannot - the reason is that OpenEmbedded builds packages based on the overall configuration, and then the image only selects which of these packages should go into the final image. However, there are some solutions that do allow you to achieve the desired result:

# Have separate packages for the two different versions. This could take the form of different recipes or you could do it within the same recipe. The two packages do have to have different names however; this may create problems if you have other packages that depend on the package.
# Use a postprocessing function within the image(s) - within the image recipe, define a shell or python function that makes the desired changes to the files in the image and add a call to it to ROOTFS_POSTPROCESS_COMMAND within the image recipe. Note that this may not be appropriate if you have runtime package management enabled since the postprocessing will only happen at image creation time and not if the package is installed later on at runtime - you may need to use a postinstall script instead in this case.
# Use a postinstall script (pkg_postinst_<package> function) within the recipe. In order to work, the postinstall script will need to be able to determine what to do when it's run - this may not be practical depending on what you're trying to achieve.

=== Can I use a toolchain built by OE as the external toolchain? ===

In general, this is not recommended and not something that is tested or directly supported out of the box. If you are wanting to do this solely as a means of speeding up the build, it is strongly suggested that you use shared state instead.

There is a [http://layers.openembedded.org/layerindex/branch/master/layer/meta-sourcery/ meta-sourcery layer] available to enable support for the CodeSourcery toolchain, you may be able to use this as a template for bringing in an external toolchain however there are no guarantees.

=== Why can't I run bitbake as root? ===

If you try to run bitbake as root you may have noticed you get a sanity check failure that prevents the build from continuing. The reason we have this check is that it is very risky to run builds as root; if any build script mistakenly tries to install files to the root path (/) instead of where it is supposed to, you want it to fail immediately and not (in the worst case) overwrite files critical to your Linux system's operation e.g. under /bin or /etc. Thus, we do not support running the build as root. The only time root access is needed is (completely outside of a build) where the runqemu script uses sudo to set up TAP devices for networking.

=== When I run bitbake -c devshell it looks like it's running as root! How is that possible? ===

It's not running as the actual root user, it's just pretending for the benefit of programs that run under it (including your shell) that it is, via pseudo. This is important, because you normally want any owner/group/permission values that you set on files to be reflected in files that the recipe installs and packages and thus reflected in the final image - without this mechanism the actual build would have to run as root which would be very risky (see above). There are no actual elevated privileges through this mechanism however, so you need not be worried.

=== Why does OE use pseudo? Why not use fakeroot / fakechroot instead? ===

Splitting this up into two questions - we use pseudo (not to be confused with sudo!) because we want to be able to create images containing files have the correct permissions and ownership, e.g. files owned by root, without the user running the build system having to have that privilege. By using LD_PRELOAD to intercept function calls, pseudo creates an environment for programs running underneath it where it appears as if the running user has those privileges (and the results of any operations persist within the pseudo environment, i.e. you can write a file as root and it will appear to be owned by root while still running under pseudo). This allows us to run builds entirely as a normal user without needing extra privileges. Without pseudo we would require running the build system under sudo or as root - which would be ill-advised for things such as "make install" in case it happened to be broken and tried to write to / instead of somewhere under the work directory for the recipe; a broken recipe could easily end up destroying your system in that case.

To answer the second part, why we use pseudo instead of fakeroot / fakechroot, see [https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot WhyNotFakeroot on the pseudo wiki].

=== How do I find out what packages are produced by a recipe? ===

The Toaster web UI provides easy ways to query this.

In the 1.8 (fido) release and newer you can use the following command, assuming the recipe has already been built:

oe-pkgdata-util list-pkgs -p <recipename>

Alternatively you can look in the "packages-split" subdirectory under the work directory for the recipe - each package produced by the recipe will have a subdirectory under that. If you're not sure how to find the work directory you can run the following command:

bitbake -e <recipename> | grep ^WORKDIR=

Before a recipe gets built it is a bit trickier, since the system often doesn't know exactly which packages will be produced until do_package time; this is particularly true for recipes that package plugins or modules (e.g. kernel modules). You can get a reasonable idea though by looking at the value of PACKAGES (and PACKAGES_DYNAMIC for recipes that produce plugins).

=== How do I find out which package contains a particular file (or python module)? ===

oe-pkgdata-util has a find-path subcommand that will tell you exactly this. For example:

$ oe-pkgdata-util find-path /etc/network/interfaces
init-ifupdown: /etc/network/interfaces

Wildcards are allowed anywhere in the path (but you should enclose such expressions in quotes to avoid the shell itself attempting to expand the wildcard):

$ oe-pkgdata-util find-path "*/fstrim"
util-linux-bash-completion: /usr/share/bash-completion/completions/fstrim
util-linux-ptest: /usr/lib/util-linux/ptest/fstrim
util-linux-dbg: /sbin/.debug/fstrim
util-linux-fstrim: /sbin/fstrim

As a specific example of where this can be useful, our Python packaging is a bit more granular than most typical distributions, allowing you to tune the contents of your image to just what you need. However, that does mean you may have trouble figuring out which package provides a particular module. oe-pkgdata-util find-path can also be used for this. For example, to find the package containing the "shutil" module, run this:

$ oe-pkgdata-util find-path "*/shutil.*"
python3-shell: /usr/lib/python3.5/shutil.py
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.opt-2.pyc
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.opt-1.pyc
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.pyc

Thus the package you are looking for is python3-shell. (Note that you could use */shutil.py, but if the module you are looking for is written in C as some of them are, that won't match it.)

=== I have a local source tree I want to build instead of the upstream source a recipe normally fetches, how do I do that? ===

If it's for development purposes i.e. you have your own local source tree you want to work on and have built, then run:

devtool modify -n <recipename> path/to/sourcetree/

Once you are done you can use <code>devtool finish</code> or <code>devtool reset</code> (depending on the situation) to return to building the source specified in the recipe.

Alternatively if it's more permanent, use the <code>externalsrc</code> class - you can inherit this in the original recipe or a bbappend:

inherit externalsrc
EXTERNALSRC = "/path/to/sources"

If you're going to use it across a number of recipes you can inherit it globally at the configuration level (perhaps via an inc file that you include/require there):

INHERIT += "externalsrc"
EXTERNALSRC_pn-<recipename> = "/path/to/sources"

=== How do I specify the default shell? (e.g. bash instead of busybox) ===

It depends what you mean. As far as which provides /bin/sh, this is controlled through the alternatives system, and by default bash has a higher priority than busybox, so simply installing bash into your image will automatically have /bin/sh link to bash rather than busybox.

If you mean you want a user's login shell to be a specific shell, you'll need to modify /etc/passwd. One fairly easy way to achieve this is to use the extrausers class in your image recipe:

inherit extrausers
EXTRA_USERS_PARAMS = "usermod -s /bin/bash <username>; "

=== How do I get "full" versions of typical shell commands? ===

Most of the shell commands in our images are provided by busybox by default, and are very much simplified compared to what you would have on a typical Linux system in order to save space. If you need the full versions, most of them are built and packaged by the coreutils recipe (for disk and other typical utilities) and procps (for ps, etc). You may also want to install bash for more typical shell built-in commands. There is also a core-image-full-cmdline image if you want a base image that is already set up to provide a more typical Linux command-line experience. (Note: these will of course use up more disk space and memory.)

=== How do I allow a variable's value through from the external environment? ===

Add the variable's name to the BB_ENV_EXTRAWHITE ''in the external environment'' before running bitbake. Note that the oe-init-build-env script sets a default for this which you will want to preserve, so add to the default value rather than overwriting it.

Alternatively if you just want to get the external value of a variable from python code within the metadata, you can use the BB_ORIGENV variable which itself contains a datastore of the original environment. For example to get the value of the DISPLAY variable from the environment within a python function you would do this:

display = d.getVar("BB_ORIGENV", False).getVar("DISPLAY")

Note that you must specify "false" for the expand parameter when getting the BB_ORIGENV variable, because it's not a string and therefore cannot be expanded in the normal manner.

=== Why is bitbake showing "AUTOINC" in the version for some recipes? ===

Recipes where you see AUTOINC within the version in the console output during a build will be those that set <code>PV</code> to include <code>"${SRCPV}"</code> to get the SCM revision (e.g. the git hash) in the package version. In order to have the version increment properly, there needs to be a number in front of the revision which automatically increments each time the revision changes (assuming you have a PR server enabled), which is where AUTOINC comes in. During the build, AUTOINC is a stand-in for this auto-incrementing number, and later during <code>do_package</code> it gets replaced with the real number so that the packages produced at the end have the full version number.

=== Why are .so files in the -dev package instead of the main package for a recipe? ===

In standard Unix library packaging, non-versioned .so symlinks (e.g. /usr/lib/libgd.so) are intended for development purposes only. At runtime, binaries should be linked to the major-versioned .so file/symlink e.g. /usr/lib/libgd.so.3. This (theoretically) allows multiple major versions of the same library as well as binaries that depend upon each of them to coexist on the same system. If the library is versioned but you have a binary that links to the unversioned .so file, it has almost certainly been linked incorrectly.

Non-symlink .so files on the other hand are sometimes produced and are entirely legal - however these will be picked up in the -dev package in OpenEmbedded simply by virtue of their name, which is almost always not what you want. In this case you can do one of two things:

# Fix the build of the library so it gets versioned. This may not always be appropriate, especially not for things like plugins.
# Set FILES_${PN}-dev within the recipe so that it does not include ${FILES_SOLIBSDEV}. If the software the recipe is building also produces symlink .so files you'll need to set FILES_${PN}-dev such that those do still get packaged in the -dev package though, or you'll get a package QA warning.

=== Can I disable shared state? ===

You cannot, no. Shared state (sstate) is an intrinsic part of staging files into the sysroot. It is possible to construct a recipe that bypasses sstate for some tasks (the kernel does this), however this is quite difficult and if not done properly will lead to many other problems.

Almost always when you are having a problem with shared state the issue is either (a) you're adding/changing files in the sysroot directly (i.e. outside sstate control), or (b) what is being placed into the sysroot isn't relocatable due to hardcoded paths. The solution for (a) is do not do that - files should always be installed under <code>${D}</code> within <code>do_install</code> and then a subset of those are staged into the sysroot automatically. For (b) you need to fix or adapt the hardcoded path(s) - if the program reads (or can be made to read) each path from an environment variable, then you can use the <code>create_wrapper</code> utility function to create a wrapper script that will set the path appropriately. Run <code>git grep create_wrapper</code> in the <code>meta</code> subdirectory to see examples.

=== Files I installed into /opt or some other path never make it into the sysroot but I need them - how do I fix this? ===

OpenEmbedded only stages a subset of files that are installed into <code>${D}</code> by <code>do_install</code> so that the sysroot doesn't fill up with unneeded files. You have two choices in this situation:
# install the files into a more standard location which is part of the subset, or
# adjust the subset to include the paths you are installing to.
Usually option 1 is recommended. If you really do need to adjust the subset, you can append the path (more specifically, the part below <code>${D}</code>) to <code>SYSROOT_DIRS</code> within your recipe. For example:

SYSROOT_DIRS += "/opt"

=== I have some software which needs to build a binary that it then runs as part of its own build process, how do I make this work? ===

Whilst it is possible to do this within a single recipe building for the target, it is tricky to do so because in that context everything is set up for cross-compiling for the target, and you would have to undo all of that to build host tools. The standard and much easier way of handling this is to create a native variant of the recipe using BBCLASSEXTEND and have your host tools built within that, and then have the target variant depend on the native variant. For example, assume your recipe were called xyz (xyz_1.1.bb), then you would include something like this in the recipe:

DEPENDS:append_class-target = " xyz-native"

...

BBCLASSEXTEND += "native"

The host tools will then be built and installed into the sysroot in the native variant ready for when the target variant starts building. If the software you are building didn't intend for those tools to be installed outside of the build tree then you may need to patch the build process (e.g. the makefile) in order to install them and possibly also for the target side to find them in the sysroot. Additionally, for performance since you only need the tools in the native variant, you may also choose to disable building everything except those tools there - e.g. by using _native overrides for variables such as EXTRA_OECONF or functions such as do_configure.

=== How do I fetch from two git repositories in the same recipe? ===

By default, sources fetched from git within a recipe are unpacked into ${WORKDIR}/git, however that only works for a single repository. If you want to fetch from more than one, you need to change the path each repository is unpacked to. This is easy to do, just add <code>;destsuffix=<subdir></code> to the end of each URL in SRC_URI (replacing <code><subdir></code> with the name of the subdirectory). You may then need to change S to match whichever of these you want to be considered the root of the source tree - or alternatively you can specify destsuffix such that repositories beyond the first go into a subdirectory under the default "git" subdirectory. For example, from the gst-libav recipe:

...
SRC_URI = " \
git://anongit.freedesktop.org/gstreamer/gst-libav;branch=1.8;name=base \
git://anongit.freedesktop.org/gstreamer/common;destsuffix=git/common;name=common \
...
"
...
S = "${WORKDIR}/git"
...

(Here we're using the default of "git" for the first repository, so we don't need to specify <code>destsuffix</code> for the first URL.)

=== I'm building a native recipe and I notice that the install path has the full path to the root directory repeated - why? ===

It does look a little odd, but the reason for doing this is that native targets are meant to run on the system they're built on and run in the location they're installed to. This means they install to a destination of "/" and PREFIX is inside the native sysroot directory. We install them to a DESTDIR to allow us to manipulate them before they then get moved to a final DESTDIR of "/".

Most Makefiles handle this correctly by doing:

DESTDIR ?= ""
prefix ?= "/usr"
bindir ?= "$(prefix)/bin"

and then, importantly, install in the form:

install -d $(DESTDIR)$(bindir)

so both prefix and DESTDIR are used. Whilst this is a convention, its a widely adopted and followed one. You can call into a custom makefile and set the variables manually if the makefile doesn't follow the convention.

=== How do I generate static libraries? ===

Its possible you have conf/distro/include/no-static-libs.inc included in your build - poky does this by default. The include list at the top of the bitbake -e output will tell you for certain.

If so, you can remove that or set:

DISABLE_STATIC = ""

as it would currently be set to this if that include file is included:

DISABLE_STATIC = " --disable-static"

Poky disables building static libraries by default as for the most part they're a waste of space/time.

=== Can I conditionally inherit a class in a recipe? ===

Yes, you can. What makes this possible is that the <code>inherit</code> keyword will not complain if what comes after it expands to being empty, so you can use in-line python to do something like this:

<pre><nowiki>
inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perlnative', '', d)}
</nowiki></pre>

The above example will inherit the <code>perlnative</code> class if "scripting" is in the value of the <code>PACKAGECONFIG</code> variable, otherwise it will do nothing.

You could of course put this into a variable if you prefer:

<pre><nowiki>
SOMEVAR = "${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perlnative', '', d)}"
inherit ${SOMEVAR}
</nowiki></pre>

=== How do I collect the source revisions fetched by each recipe? ===

If you have recipes where <code>SRCREV = "${AUTOREV}"</code> then you won't necessarily know exactly which revisions were built after the fact - it will be whatever was current at the time. You also might alternatively just want to get all of the revisions. Either way, to do this, enable buildhistory by setting the following in your local.conf:

<pre><nowiki>
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
</nowiki></pre>

(The last line is not required with version 2.5 and onwards as it is the default, but will do no harm.)

Once you have enabled buildhistory, you then need to build your image again so that buildhistory has a chance to record history data for it. Following that you can run <code>buildhistory-collect-srcrevs</code> (with <code>-a</code> if you want to see all revisions, not just the ones where AUTOREV was used) and it will output the revisions in a form you can use in a .inc file that you can <code>require</code> from your configuration if you want to fix the build to those revisions.

For more information see the [https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#maintaining-build-output-quality Maintaining Build Output Quality] section of the Yocto Project Development manual, which covers the buildhistory class in detail.

=== How do I do an offline build with recipes that have <code>SRCREV = "${AUTOREV}"</code> set? ===

If you set <code>BB_NO_NETWORK = "1"</code> and you have recipes that have <code>SRCREV = "${AUTOREV}"</code>, you will get an error because the build system will try to check the latest revision on startup and be immediately blocked by <code>BB_NO_NETWORK</code>. There are two ways to handle this:

A) See the previous question "How do I collect the source revisions fetched by each recipe?" and use the output generated by <code>buildhistory-collect-srcrevs</code> as a .inc file in your configuration in order to fix the revisions at the ones which were most recently built.

or

B) Set <code>BB_SRCREV_POLICY = "cache"</code> in your configuration. This will use the last cached revision. (The disadvantage of this method is that it is a little more difficult to preserve or share with others the fixed revisions.)

Note that in either case if you later want to build the latest version again, you will of course need to undo the configuration changes.

=== Is it possible to append a bbclass file (like bbappends do for recipes)? ===

No, see the next question for details.

=== How do I override a bbclass file? ===

This is tricky - bbclass files are found via BBPATH, which is added to by each layer.conf either by prepending or appending. Assuming you are putting your bbclass in a custom layer, you will probably want to have your layer's layer.conf prepend to BBPATH, but then you will also need to make sure that your layer does not appear before any other layer that is also prepending and overriding the same class.

Another alternative is to have an additional class which makes the appropriate changes to the environment, and then you will need to inherit that class after (and in the same manner as) the original class. This is slightly cleaner but can be annoying to enable particularly if the class is inherited by a number of recipes, and won't work if you want to alter the behaviour of a class inherited by recipes you don't control. (If you want a class to be inherited for all images (i.e. all recipes inheriting the <code>image</code> class) you can inject additional classes by setting IMAGE_CLASSES; similarly for the kernel there is KERNEL_CLASSES).

Ultimately, overriding bbclass files is not good practice long term - you are opening yourself up to maintenance issues when the original class changes, and the override is fragile as hinted above. The best solution is to try to get whatever changes you need into the original class; this does of course require additional work and time though.

=== There's a bbappend in a layer I'm using that defines a <code>do_something:append()</code> and I want to append to that function also, how do I do this? ===

Simply create a bbappend in your layer and define your own <code>do_something:append()</code>, and your commands will be executed ''as well as'' those of the other bbappend.

You might assume that defining <code>do_something:append()</code> will overwrite any previously defined <code>do_something:append()</code>, as would be the case with <code>do_something()</code> in the same situation, but that is not the case - the key is that <code>:append</code> (and <code>:prepend</code>, <code>:remove</code>, etc.) are ''operators'' and they will be applied in sequence, where that sequence is the order in which they are parsed (which for bbappends will be in ascending layer priority order).

Technical FAQ

2023-12-23T20:30:15Z

Simonew: Fix syntax

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
| '''NOTE:''' This is currently a draft. Not sure where this should end up but I've been gathering these based on my interactions with people on IRC and email over the years. - [[User:PaulEggleton|PaulEggleton]] ([[User talk:PaulEggleton|talk]]) 21:13, 27 June 2016 (PDT)
|}

== Basics ==

=== How do I figure out which version/codename/bitbake version matches up with which? ===

There is a table in the [http://wiki.yoctoproject.org/wiki/Releases Releases page] on the Yocto Project wiki.

=== How do I control what's in the final image? ===

Each image is defined by its own recipe, and that recipe specifies a list of packages that the image should contain. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Customising Images] within the Yocto Project development manual for further details.

Note: if you're doing anything more than basic experimentation / testing then you almost certainly should create your own image recipe rather than using one of the example images e.g. core-image-minimal - though you can certainly start by copying one of the example images. This way you have easier control over what goes into the image.

=== Where do I find build logs? ===

For the overall build, the output of bitbake gets logged to tmp/log/cooker/<machine>.

For each individual recipe, there is a "temp" directory under the work directory for the recipe that contains log.<taskname> and run.<taskname> files - the logs and the runfiles respectively. Within the build system this directory is pointed to by the T variable, so if you need to you can find it by using <code>bitbake -e</code>:

bitbake -e <recipename> | grep ^T=

=== How do I add a patch to a recipe? ===

There are two concerns - how the recipe can fetch the patch and how it can be applied. For fetching, patch files are usually placed in a subdirectory next to the recipe; by default this directory should be named "files" or the the recipe name without any class prefix or suffix (for example for both "xyz" and "xyz-native" the subdirectory would be "xyz"). A pointer to it then needs to be added to <code>SRC_URI</code> within the recipe, which usually takes the form <code>file://<patchname>.patch</code> - i.e. just the filename, no path. If more than one subdirectory needs to be stripped off the paths in the patch (i.e. you need more than the equivalent of the -p1 option to the patch command) then you can add <code>;striplevel=<number></code> to the end of the patch entry in SRC_URI (without any spaces).

As with any modification, if the patch you are applying is a customisation that you do not intend to send to be incorporated in the layer you are modifying, then instead of adding the patch to the recipe directly then you should consider applying it in a bbappend within your own custom layer. This makes things easier if you later want to update the layer in question and the recipe has been modified upstream - you avoid effectively forking the layer.

The <code>devtool</code> utility can help you modify the sources for a recipe and create a patch - basically <code>devtool modify</code>, edit the sources, commit the changes with <code>git commit</code>, then <code>devtool finish</code> (or <code>devtool update-recipe</code> in versions older than 2.2). Since <code>devtool modify</code> gives you a git tree to work with, you can of course use something like <code>git am</code> to apply existing patches this way. For more details see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#devtool-use-devtool-modify-to-enable-work-on-code-associated-with-an-existing-recipe Use devtool modify to Enable Work on Code Associated with an Existing Recipe] within the Yocto Project Development manual.

=== What does "native" mean? ===

The "native" suffix identifies recipes (and variants of recipes) that produce files intended for the build host, as opposed to the target machine. This is usually for tools that are needed during the build process (such as automake).

=== What does "nativesdk" mean? ===

The "nativesdk" prefix identifies recipes (and variants of recipes) that produce files intended for the host portion of the standard SDK, or for things which are constructed like an SDK such as buildtools-tarball. These are built for SDKMACHINE which may or may not be the same architecture as the build host.

=== I have two recipes and one needs to access files provided by another - how can that work? ===

Instead of providing direct access from a recipe to another's build tree (which wouldn't be practical with OpenEmbedded since the build tree (or "workdir") is temporary), we create a "sysroot" where files that are intended to be shared between recipes get copied. The sysroot is managed by the build system and you should not copy files in there directly - instead, you install files under ${D} as normal during do_install and then the build system will copy a subset of those to the sysroot. There is a seperate sysroot for each machine being built for. In a recipe you can get the path of the sysroot and various standard directories under it using the STAGING_* variables.

Often, for commonly-used build systems such as autotools and cmake you don't need to worry about these details - those systems and the environment that OpenEmbedded sets up for them will ensure that files get installed and picked up in the correct locations. However if the software your recipe is building has custom build scripts / makefiles and it takes shortcuts that don't account for cross-compilation or the use of a sysroot, then you will need to make appropriate adjustments.

=== How do I enable package management in the final image? ===

Add <code>package-management</code> to <code>IMAGE_FEATURES</code> (or <code>EXTRA_IMAGE_FEATURES</code>). You should then be able to use dnf/rpm, opkg, or apt-get/dpkg from the running system depending on the packaging format you have selected through PACKAGE_CLASSES. For more information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management Using Runtime Package Management] in the Yocto Project Development manual.

=== What do ?=, ??=, := etc. do within a recipe/config file? ===

See the [http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#basic-syntax Basic Syntax section of the BitBake manual] for details.

== Layers ==

See http://www.openembedded.org/Layers_FAQ

== Troubleshooting ==

=== I've created a recipe but it's not showing up in my image, what's going on? ===

Creating a recipe (or adding a layer to your configuration with a desired recipe in it) only makes it available to the build system, it doesn't change what goes into the image. For that, see [[#How do I control what's in the final image?|How do I control what's in the final image?]] above.

=== I set a variable but it doesn't seem to be having an effect, how do I fix this? ===

First, double-check that you haven't misspelled the variable name.

The main tool to help troubleshoot any variable-related issue is <code>bitbake -e</code> - this lists all the variables and the complete history of how each one has been set (use <code>bitbake -e <recipename></code> if you're dealing with issues in a variable value within a recipe as opposed to the global level). Usually it's best to pipe this through <code>less</code> so you can easily see the history - within less you can press / to search for the variable name. Often you will be dealing with the behaviour of a variable within the context of a specific recipe, so specify that recipe on the <code>bitbake -e</code> command line to get the variables as set within the context of the recipe rather than the global context.

If you're setting a variable in a bbappend, double-check that the bbappend is actually being applied - see the next question.

=== I've created a bbappend for a recipe but what I'm setting there isn't having any effect, how do I fix this? ===

Here are some things to check:

# Check if the layer the bbappend is in is listed in <code>bitbake-layers show-layers</code>. If it isn't, you need to edit your bblayers.conf and ensure the path to the layer is included in the BBLAYERS value
# Check that the bbappend is being picked up by running <code>bitbake-layers show-appends</code> - if your bbappend file isn't listed, it could be named incorrectly (such that it doesn't match the recipe name) or it may be that the BBFILES value in the conf/layer.conf for the layer containing the bbappend file doesn't include an expression that will match the bbappend files.
# If there are multiple versions of the recipe you have bbappended, it could be that the actual recipe being built is a different version than the one you have bbappended. <code>bitbake-layers show-recipes <recipename></code> will list all the versions, with the first one listed being the one that will be built. If this is the case there are several different solutions to this - (a) Rename your bbappend to match the version being built, (b) use a % wildcard in your bbappend so it will apply to any version, (c) set <code>PREFERRED_VERSION_<recipename></code> in the configuration to select a the version you want to be built.
# Finally, as with any other issue with setting variables, use <code>bitbake -e <recipename> | less</code> and search with <code>/</code> to see the history of how the variable has been set - you may find that the value you're trying set is being overridden.

=== I'm getting warnings that a recipe is tainted - what does this mean? ===

Usually this happens because you have used I used bitbake's <code>-f</code> or <code>-C</code> option to force a task to re-execute. The assumption is that if you forced a task, it is possible that a rebuild from scratch would not include whatever changes you made that necessitated forcing (e.g. if you modified the source in the work directory for the recipe and then ran <code>bitbake -c compile -f</code>). Generally, forcing a task should be reserved for situations where the build system has failed to detect a change you made rather than for everyday usage - if you're finding yourself needing to do it regularly then either there's a bug, you're doing something wrong, or perhaps you're using <code>-f</code> or <code>-C</code> when it's not really needed. Running <code>bitbake -c clean</code> on the recipe will get rid of the taint flag.

There is one other situation where we apply a taint, and that is <code>bitbake -c menuconfig</code> on the kernel (or some other kconfig-using recipe). In this case, the configuration has been saved into the work directory for the kernel, but that is temporary - any rebuild from scratch will use the default configuration, so it is a reminder that you need to take the configuration and apply it back to the metadata and then run <code>bitbake -c clean</code> on the kernel recipe.

=== I'm fetching from a git repository over ssh / http / https but it's not fetching properly, how do I fix this? ===

Bitbake expects the prefix of entries in SRC_URI to specify the fetcher to be used, not the actual protocol. Thus, instead of:

# This will NOT work
SRC_URI = "<nowiki>https://git.example.com/repository</nowiki>"

You should specify:

# This is better
SRC_URI = "<nowiki>git://git.example.com/repository;protocol=https</nowiki>"

The same applies for ssh and of course http.

=== I tried bitbake <some target package name> that I know exists and it told me that nothing PROVIDES this...? ===

There are two namespaces that bitbake concerns itself with - recipe names (a.k.a. build time targets) and package names (a.k.a. runtime targets). You can specify a build time target on the bitbake command line, but not a runtime target; you need to find the recipe that provides the package you are trying to build and build that instead (or simply add that package to your image and build the image). In current versions bitbake will at least tell you which recipes have matching or similar-sounding runtime provides (RPROVIDES) so that you'll usually get a hint on which recipe you need to build.

=== I've included a package in my image but files I expect to be there are missing, what's the issue? ===

Check the simple stuff: verify that the package is really in the image - look at the manifest file next to the image to ensure the package is listed. Also if you're flashing the image, double-check that you did indeed flash the right image and if there are multiple partitions / storage devices on your board or device that you're booting the one that you think you are.

Once you're sure of the above, it may be a matter of the package splitting - a lot of recipes split less commonly used components out to separate packages, so it's possible that the files you are looking for are in a different package. You can look at the recipe for this (look for PACKAGES and FILES statements) or assuming the recipe has been built, you can use <code>oe-pkgdata-util list-pkgs -p <recipename></code> and <code>oe-pkgdata-util list-pkg-files</code> to inspect the packages provided by the recipe and the files they contain. Once you find the right package you can add it to your image.

=== I'm required to set LIC_FILES_CHKSUM but the software I'm building doesn't have a license statement, what do I do? ===

Ideally, all software should come with some kind of license statement so that the terms of distribution are clearly stated (especially if its source code is made publicly available); if not a text file describing the license then at the very least a line or two in the accompanying documentation, README file or source header comments. Assuming there is a license statement somewhere but not in a form you can point to with LIC_FILES_CHKSUM as part of the source tree, you can point LIC_FILES_CHKSUM to one of the generic license files in ${COMMON_LICENSE_DIR} (meta/files/common-licenses/), or alternatively you can include a file containing the license statement in a "files" subdirectory next to the recipe (or subdirectory named the same as the recipe - see how such files are handled in other recipes), point to it in SRC_URI using file://, then add it to LIC_FILES_CHKSUM. It is worth noting however that LIC_FILES_CHKSUM is intended to give you a warning if upstream changes its license terms when you do an upgrade of the recipe, and by pointing it to this common license file that is part of the metadata, that mechanism will not function. You may wish to consider encouraging the upstream provider of the software your recipe is building to follow best practices and include a proper license statement, so that you can point to it in a future version. At minimum if you do use such workarounds, you will need to take extra care when upgrading the recipe in future in case the upstream provider changes the license terms.

If there really is no license stated at all anywhere for the software (and this is unfortunately not uncommon on github, for example) then you should really contact upstream - if there's no license, then technically you really shouldn't be distributing it until that's clarified with the original author(s).

=== I am getting a package QA error / warning when building a recipe, how do I solve it? ===

There are some general and specific recommendations in the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings QA Errors and Warnings] section of the Yocto Project Reference Manual.

=== I am getting "taskhash mismatch" errors, what does this mean and how do I fix it? ===

Bitbake parses the metadata (recipes, classes and configuration) repeatedly during its operation, and this error means that the result of parsing changed between one parse and the next. Two situations that can cause this:
# One of the parsed files changed in between e.g. you edited a recipe or performed a git operation (e.g. git checkout) during the build. '''Do not make changes to the metadata while a build is running.''' If you run the build again the error should not recur.
# Alternatively, there is something in the metadata that results in a variable expanding to a different value each time it is parsed. This is often something time-related e.g. a timestamp which is calculated every time an expression is expanded. The solution is to ensure the value is calculated once per build and then the expression expands to the same value for the duration of the build.

=== Building on a system with a GRSec kernel doesn't work well, is that supported? ===

No, grsec isn't really supported. The list of distros that are supported (tested) is in the Yocto mega manual for each release.
You can refer to the work-around given in this defect: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10885

=== Working around Firejail ===
For users of Parrot OS and other secured Linux distros, you will find that your bitbake fetch commands refuse to work, yet you can manually run wget and retrieve the packages with no problem. This is due to Poky creating links to all the tools it requires, in particular 'wget', 'ssh' and 'strings', using the links to these tools in the /usr/local/bin/ directory which all redirect to firejail. To fix the problem you can cd into <your Yocto install directory>/poky/build/tmp/hosttools directory and replace these links with ones redirecting to the actual executables under the /usr/bin directory.

== Dependencies ==

=== How do I find out why something is being built? ===

<code>bitbake -g <recipe></code> will produce some .dot files that allow you to see the dependency relationships - usually pn-depends.dot holds the answers although sometimes you may need to look at task-depends.dot if the dependency is only in the form of a task dependency. Note that these graphs are much too large for most graphviz visualisation tools to process, so you'll probably find it's easiest to view them with "less" or a text editor and search for the item you're looking for.

=== How do I find out why something is in my image? ===

Enable the buildhistory class and build the image again, and it will write out a depends.dot file containing the relationships between packages in the final image. If the package name isn't mentioned it is probably explicitly mentioned in IMAGE_INSTALL or being brought in via IMAGE_FEATURES.

See [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Maintaining Build Output Quality] in the Yocto Project Reference manual which covers how to enable buildhistory and the output it produces.

=== How do I view the .dot files produced by bitbake -g or buildhistory? ===

The size of some of these .dot graphs (particularly those produced by <code>bitbake -g</code>) is a little large for most viewers / processing tools, and unfortunately this isn't something that can be fixed - it's just the nature of the dependency relationships between targets and tasks within OpenEmbedded. Usually if you're just after answering a simple dependency question you can figure it out by viewing it with <code>less</code> and using its built-in search function (or alternatively your favourite text editor).

You can try [http://github.com/jrfonseca/xdot.py xdot] which will work well for some of the graphs, but the task graph produced by <code>bitbake -g</code> for something like an image in particular is likely to be too large to view within it.

=== Why are all of these -native items being built when my host distro has some of these available? ===

It's complicated. In some cases the software in question isn't widely packaged by common Linux distributions. In other cases we need to apply patches to the software, use a more up-to-date version than commonly packaged or build it with a particular configuration. In general it just helps us isolate ourselves from potential problems caused by differences in host Linux distributions. For the most part the time spent building the native tools that are definitely provided by the host distro are dwarfed by the time spent building things that definitely aren't provided, such as the C library for the target and the cross-compiling toolchain.

=== I disabled runtime package management and yet it still seems to be building rpm/opkg, why? ===

The build system always uses a package manager on the host to assemble images, because it is usually the best tool for this job. This is completely independent of whether the package manager is available in the target image - "package-management" being in IMAGE_FEATURES (possibly indirectly via EXTRA_IMAGE_FEATURES) controls whether the package manager is used at runtime i.e. whether it (and its associated package database) will be present in the target image.

=== Why is opkg-native / opkg-utils being built when I don't have ipk packaging enabled? ===

opkg-utils provides update-alternatives which is the default tool used to manage the alternatives system (for selecting between multiple providers of the same file, e.g. busybox and bash both provide /bin/sh).

=== Why is rpm-native being built when I don't have rpm packaging enabled? ===

rpm-native is needed for two things in the generic packaging code implemented in the package class:

# Debug symbol splitting - rpm-native provides the debugedit tool which this code uses
# Per-file dependencies - although this was originally just feeding into rpm when rpm was being used, it also now gets verified by QA checks regardless of which packaging backend is in use.

=== I see a recipe built, but building an image containing the corresponding package fails at do_rootfs because it can't find the package. How does this happen? ===

(For ipk, the error is "Couldn't find anything to satisfy '<package>'"; for rpm it is "<package> not found in the base feeds (<architecture list>)".)

Usually this is because the recipe claimed to provide the specified package (via PACKAGES or PACKAGES_DYNAMIC) but it wasn't actually produced, possibly because it ended up empty (since by default empty packages aren't produced), but the image or some other package still has a dependency that pulls in the specified package. If this is a recipe you are writing yourself the probable cause is your recipe isn't installing any files and thus the main package for the recipe is empty. Fix do_install (or what do_install is already running, e.g. make install) such that files are installed into the correct location such that they can then subsequently be packaged, and then all should be well.

In other situations the reference to the package in question is spurious and either it should be removed entirely or there's another package that should be used instead. For example, the avahi and dhcp recipes both have an empty main package since the client and server are split out into their own packages, and those are the ones you should be using instead (avahi-daemon, avahi-utils, dhcp-server, dhcp-client - there are other packages as well, please see [[#How_do_I_find_out_what_packages_are_produced_by_a_recipe.3F|How do I find out what packages are produced by a recipe?]].) You could argue that these recipes shouldn't claim to provide the main package, or they should have a main package that depends on all the other packages (as some other recipes do).

=== X11 and various other items are being built but I'm only building core-image-minimal that doesn't have X11 in it - why? ===

This is where it helps to understand the difference between build-time dependencies and runtime dependencies - often, a recipe will require things at build time (for example tools that help the build process, or to satisfy optional dependencies) that it doesn't necessarily need at runtime. The default configuration includes "<code>x11</code>" in <code>DISTRO_FEATURES</code>, and thus anything that can optionally support X11 will have its X11 support enabled; however when it comes to actually producing the image there won't be any X11 packages included as long as there are no hard dependencies and there aren't any X11 packages explicitly requested.

If you never intend to use X11, you can set your own <code>DISTRO_FEATURES</code> value that excludes <code>x11</code> (note lower case, as with all feature names) and then X11 support will be disabled at build time and these items won't even be built.

=== How do I avoid the kernel itself being pulled into my image when installing kernel modules? ===

By default, the kernel class sets a dependency on the kernel-base package (which kernel modules always depend on) onto kernel-image, which contains the actual kernel binary. If you don't want this, set the following either in your kernel recipe or at the configuration level:

RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""

Note: for older releases (pre-2.5) do this instead:

RDEPENDS_kernel-base = ""

== Misc ==

=== How do I remove a value from a list variable? ===

For variables that are expected to contain a space-separated list of items, BitBake supports a _remove operator to remove items from it. See [http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#removing-override-style-syntax Removal (override style syntax)] in the BitBake user manual.

'''NOTE:''' the _remove operation is final - you cannot "undo" it with other operations elsewhere, thus you should really only make use of it in your distro / local configuration and not in layers that you expect others to re-use for different purposes (and therefore they may need to undo your changes). An alternative way to effectively remove an item is to set the list outright to include all the items minus the one you want to remove.

=== How do I change how my recipe is built depending on what image I'm building? ===

The short answer is you cannot - the reason is that OpenEmbedded builds packages based on the overall configuration, and then the image only selects which of these packages should go into the final image. However, there are some solutions that do allow you to achieve the desired result:

# Have separate packages for the two different versions. This could take the form of different recipes or you could do it within the same recipe. The two packages do have to have different names however; this may create problems if you have other packages that depend on the package.
# Use a postprocessing function within the image(s) - within the image recipe, define a shell or python function that makes the desired changes to the files in the image and add a call to it to ROOTFS_POSTPROCESS_COMMAND within the image recipe. Note that this may not be appropriate if you have runtime package management enabled since the postprocessing will only happen at image creation time and not if the package is installed later on at runtime - you may need to use a postinstall script instead in this case.
# Use a postinstall script (pkg_postinst_<package> function) within the recipe. In order to work, the postinstall script will need to be able to determine what to do when it's run - this may not be practical depending on what you're trying to achieve.

=== Can I use a toolchain built by OE as the external toolchain? ===

In general, this is not recommended and not something that is tested or directly supported out of the box. If you are wanting to do this solely as a means of speeding up the build, it is strongly suggested that you use shared state instead.

There is a [http://layers.openembedded.org/layerindex/branch/master/layer/meta-sourcery/ meta-sourcery layer] available to enable support for the CodeSourcery toolchain, you may be able to use this as a template for bringing in an external toolchain however there are no guarantees.

=== Why can't I run bitbake as root? ===

If you try to run bitbake as root you may have noticed you get a sanity check failure that prevents the build from continuing. The reason we have this check is that it is very risky to run builds as root; if any build script mistakenly tries to install files to the root path (/) instead of where it is supposed to, you want it to fail immediately and not (in the worst case) overwrite files critical to your Linux system's operation e.g. under /bin or /etc. Thus, we do not support running the build as root. The only time root access is needed is (completely outside of a build) where the runqemu script uses sudo to set up TAP devices for networking.

=== When I run bitbake -c devshell it looks like it's running as root! How is that possible? ===

It's not running as the actual root user, it's just pretending for the benefit of programs that run under it (including your shell) that it is, via pseudo. This is important, because you normally want any owner/group/permission values that you set on files to be reflected in files that the recipe installs and packages and thus reflected in the final image - without this mechanism the actual build would have to run as root which would be very risky (see above). There are no actual elevated privileges through this mechanism however, so you need not be worried.

=== Why does OE use pseudo? Why not use fakeroot / fakechroot instead? ===

Splitting this up into two questions - we use pseudo (not to be confused with sudo!) because we want to be able to create images containing files have the correct permissions and ownership, e.g. files owned by root, without the user running the build system having to have that privilege. By using LD_PRELOAD to intercept function calls, pseudo creates an environment for programs running underneath it where it appears as if the running user has those privileges (and the results of any operations persist within the pseudo environment, i.e. you can write a file as root and it will appear to be owned by root while still running under pseudo). This allows us to run builds entirely as a normal user without needing extra privileges. Without pseudo we would require running the build system under sudo or as root - which would be ill-advised for things such as "make install" in case it happened to be broken and tried to write to / instead of somewhere under the work directory for the recipe; a broken recipe could easily end up destroying your system in that case.

To answer the second part, why we use pseudo instead of fakeroot / fakechroot, see [https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot WhyNotFakeroot on the pseudo wiki].

=== How do I find out what packages are produced by a recipe? ===

The Toaster web UI provides easy ways to query this.

In the 1.8 (fido) release and newer you can use the following command, assuming the recipe has already been built:

oe-pkgdata-util list-pkgs -p <recipename>

Alternatively you can look in the "packages-split" subdirectory under the work directory for the recipe - each package produced by the recipe will have a subdirectory under that. If you're not sure how to find the work directory you can run the following command:

bitbake -e <recipename> | grep ^WORKDIR=

Before a recipe gets built it is a bit trickier, since the system often doesn't know exactly which packages will be produced until do_package time; this is particularly true for recipes that package plugins or modules (e.g. kernel modules). You can get a reasonable idea though by looking at the value of PACKAGES (and PACKAGES_DYNAMIC for recipes that produce plugins).

=== How do I find out which package contains a particular file (or python module)? ===

oe-pkgdata-util has a find-path subcommand that will tell you exactly this. For example:

$ oe-pkgdata-util find-path /etc/network/interfaces
init-ifupdown: /etc/network/interfaces

Wildcards are allowed anywhere in the path (but you should enclose such expressions in quotes to avoid the shell itself attempting to expand the wildcard):

$ oe-pkgdata-util find-path "*/fstrim"
util-linux-bash-completion: /usr/share/bash-completion/completions/fstrim
util-linux-ptest: /usr/lib/util-linux/ptest/fstrim
util-linux-dbg: /sbin/.debug/fstrim
util-linux-fstrim: /sbin/fstrim

As a specific example of where this can be useful, our Python packaging is a bit more granular than most typical distributions, allowing you to tune the contents of your image to just what you need. However, that does mean you may have trouble figuring out which package provides a particular module. oe-pkgdata-util find-path can also be used for this. For example, to find the package containing the "shutil" module, run this:

$ oe-pkgdata-util find-path "*/shutil.*"
python3-shell: /usr/lib/python3.5/shutil.py
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.opt-2.pyc
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.opt-1.pyc
python3-shell: /usr/lib/python3.5/__pycache__/shutil.cpython-35.pyc

Thus the package you are looking for is python3-shell. (Note that you could use */shutil.py, but if the module you are looking for is written in C as some of them are, that won't match it.)

=== I have a local source tree I want to build instead of the upstream source a recipe normally fetches, how do I do that? ===

If it's for development purposes i.e. you have your own local source tree you want to work on and have built, then run:

devtool modify -n <recipename> path/to/sourcetree/

Once you are done you can use <code>devtool finish</code> or <code>devtool reset</code> (depending on the situation) to return to building the source specified in the recipe.

Alternatively if it's more permanent, use the <code>externalsrc</code> class - you can inherit this in the original recipe or a bbappend:

inherit externalsrc
EXTERNALSRC = "/path/to/sources"

If you're going to use it across a number of recipes you can inherit it globally at the configuration level (perhaps via an inc file that you include/require there):

INHERIT += "externalsrc"
EXTERNALSRC_pn-<recipename> = "/path/to/sources"

=== How do I specify the default shell? (e.g. bash instead of busybox) ===

It depends what you mean. As far as which provides /bin/sh, this is controlled through the alternatives system, and by default bash has a higher priority than busybox, so simply installing bash into your image will automatically have /bin/sh link to bash rather than busybox.

If you mean you want a user's login shell to be a specific shell, you'll need to modify /etc/passwd. One fairly easy way to achieve this is to use the extrausers class in your image recipe:

inherit extrausers
EXTRA_USERS_PARAMS = "usermod -s /bin/bash <username>; "

=== How do I get "full" versions of typical shell commands? ===

Most of the shell commands in our images are provided by busybox by default, and are very much simplified compared to what you would have on a typical Linux system in order to save space. If you need the full versions, most of them are built and packaged by the coreutils recipe (for disk and other typical utilities) and procps (for ps, etc). You may also want to install bash for more typical shell built-in commands. There is also a core-image-full-cmdline image if you want a base image that is already set up to provide a more typical Linux command-line experience. (Note: these will of course use up more disk space and memory.)

=== How do I allow a variable's value through from the external environment? ===

Add the variable's name to the BB_ENV_EXTRAWHITE ''in the external environment'' before running bitbake. Note that the oe-init-build-env script sets a default for this which you will want to preserve, so add to the default value rather than overwriting it.

Alternatively if you just want to get the external value of a variable from python code within the metadata, you can use the BB_ORIGENV variable which itself contains a datastore of the original environment. For example to get the value of the DISPLAY variable from the environment within a python function you would do this:

display = d.getVar("BB_ORIGENV", False).getVar("DISPLAY")

Note that you must specify "false" for the expand parameter when getting the BB_ORIGENV variable, because it's not a string and therefore cannot be expanded in the normal manner.

=== Why is bitbake showing "AUTOINC" in the version for some recipes? ===

Recipes where you see AUTOINC within the version in the console output during a build will be those that set <code>PV</code> to include <code>"${SRCPV}"</code> to get the SCM revision (e.g. the git hash) in the package version. In order to have the version increment properly, there needs to be a number in front of the revision which automatically increments each time the revision changes (assuming you have a PR server enabled), which is where AUTOINC comes in. During the build, AUTOINC is a stand-in for this auto-incrementing number, and later during <code>do_package</code> it gets replaced with the real number so that the packages produced at the end have the full version number.

=== Why are .so files in the -dev package instead of the main package for a recipe? ===

In standard Unix library packaging, non-versioned .so symlinks (e.g. /usr/lib/libgd.so) are intended for development purposes only. At runtime, binaries should be linked to the major-versioned .so file/symlink e.g. /usr/lib/libgd.so.3. This (theoretically) allows multiple major versions of the same library as well as binaries that depend upon each of them to coexist on the same system. If the library is versioned but you have a binary that links to the unversioned .so file, it has almost certainly been linked incorrectly.

Non-symlink .so files on the other hand are sometimes produced and are entirely legal - however these will be picked up in the -dev package in OpenEmbedded simply by virtue of their name, which is almost always not what you want. In this case you can do one of two things:

# Fix the build of the library so it gets versioned. This may not always be appropriate, especially not for things like plugins.
# Set FILES_${PN}-dev within the recipe so that it does not include ${FILES_SOLIBSDEV}. If the software the recipe is building also produces symlink .so files you'll need to set FILES_${PN}-dev such that those do still get packaged in the -dev package though, or you'll get a package QA warning.

=== Can I disable shared state? ===

You cannot, no. Shared state (sstate) is an intrinsic part of staging files into the sysroot. It is possible to construct a recipe that bypasses sstate for some tasks (the kernel does this), however this is quite difficult and if not done properly will lead to many other problems.

Almost always when you are having a problem with shared state the issue is either (a) you're adding/changing files in the sysroot directly (i.e. outside sstate control), or (b) what is being placed into the sysroot isn't relocatable due to hardcoded paths. The solution for (a) is do not do that - files should always be installed under <code>${D}</code> within <code>do_install</code> and then a subset of those are staged into the sysroot automatically. For (b) you need to fix or adapt the hardcoded path(s) - if the program reads (or can be made to read) each path from an environment variable, then you can use the <code>create_wrapper</code> utility function to create a wrapper script that will set the path appropriately. Run <code>git grep create_wrapper</code> in the <code>meta</code> subdirectory to see examples.

=== Files I installed into /opt or some other path never make it into the sysroot but I need them - how do I fix this? ===

OpenEmbedded only stages a subset of files that are installed into <code>${D}</code> by <code>do_install</code> so that the sysroot doesn't fill up with unneeded files. You have two choices in this situation:
# install the files into a more standard location which is part of the subset, or
# adjust the subset to include the paths you are installing to.
Usually option 1 is recommended. If you really do need to adjust the subset, you can append the path (more specifically, the part below <code>${D}</code>) to <code>SYSROOT_DIRS</code> within your recipe. For example:

SYSROOT_DIRS += "/opt"

=== I have some software which needs to build a binary that it then runs as part of its own build process, how do I make this work? ===

Whilst it is possible to do this within a single recipe building for the target, it is tricky to do so because in that context everything is set up for cross-compiling for the target, and you would have to undo all of that to build host tools. The standard and much easier way of handling this is to create a native variant of the recipe using BBCLASSEXTEND and have your host tools built within that, and then have the target variant depend on the native variant. For example, assume your recipe were called xyz (xyz_1.1.bb), then you would include something like this in the recipe:

DEPENDS_append_class-target = " xyz-native"

...

BBCLASSEXTEND += "native"

The host tools will then be built and installed into the sysroot in the native variant ready for when the target variant starts building. If the software you are building didn't intend for those tools to be installed outside of the build tree then you may need to patch the build process (e.g. the makefile) in order to install them and possibly also for the target side to find them in the sysroot. Additionally, for performance since you only need the tools in the native variant, you may also choose to disable building everything except those tools there - e.g. by using _native overrides for variables such as EXTRA_OECONF or functions such as do_configure.

=== How do I fetch from two git repositories in the same recipe? ===

By default, sources fetched from git within a recipe are unpacked into ${WORKDIR}/git, however that only works for a single repository. If you want to fetch from more than one, you need to change the path each repository is unpacked to. This is easy to do, just add <code>;destsuffix=<subdir></code> to the end of each URL in SRC_URI (replacing <code><subdir></code> with the name of the subdirectory). You may then need to change S to match whichever of these you want to be considered the root of the source tree - or alternatively you can specify destsuffix such that repositories beyond the first go into a subdirectory under the default "git" subdirectory. For example, from the gst-libav recipe:

...
SRC_URI = " \
git://anongit.freedesktop.org/gstreamer/gst-libav;branch=1.8;name=base \
git://anongit.freedesktop.org/gstreamer/common;destsuffix=git/common;name=common \
...
"
...
S = "${WORKDIR}/git"
...

(Here we're using the default of "git" for the first repository, so we don't need to specify <code>destsuffix</code> for the first URL.)

=== I'm building a native recipe and I notice that the install path has the full path to the root directory repeated - why? ===

It does look a little odd, but the reason for doing this is that native targets are meant to run on the system they're built on and run in the location they're installed to. This means they install to a destination of "/" and PREFIX is inside the native sysroot directory. We install them to a DESTDIR to allow us to manipulate them before they then get moved to a final DESTDIR of "/".

Most Makefiles handle this correctly by doing:

DESTDIR ?= ""
prefix ?= "/usr"
bindir ?= "$(prefix)/bin"

and then, importantly, install in the form:

install -d $(DESTDIR)$(bindir)

so both prefix and DESTDIR are used. Whilst this is a convention, its a widely adopted and followed one. You can call into a custom makefile and set the variables manually if the makefile doesn't follow the convention.

=== How do I generate static libraries? ===

Its possible you have conf/distro/include/no-static-libs.inc included in your build - poky does this by default. The include list at the top of the bitbake -e output will tell you for certain.

If so, you can remove that or set:

DISABLE_STATIC = ""

as it would currently be set to this if that include file is included:

DISABLE_STATIC = " --disable-static"

Poky disables building static libraries by default as for the most part they're a waste of space/time.

=== Can I conditionally inherit a class in a recipe? ===

Yes, you can. What makes this possible is that the <code>inherit</code> keyword will not complain if what comes after it expands to being empty, so you can use in-line python to do something like this:

<pre><nowiki>
inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perlnative', '', d)}
</nowiki></pre>

The above example will inherit the <code>perlnative</code> class if "scripting" is in the value of the <code>PACKAGECONFIG</code> variable, otherwise it will do nothing.

You could of course put this into a variable if you prefer:

<pre><nowiki>
SOMEVAR = "${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perlnative', '', d)}"
inherit ${SOMEVAR}
</nowiki></pre>

=== How do I collect the source revisions fetched by each recipe? ===

If you have recipes where <code>SRCREV = "${AUTOREV}"</code> then you won't necessarily know exactly which revisions were built after the fact - it will be whatever was current at the time. You also might alternatively just want to get all of the revisions. Either way, to do this, enable buildhistory by setting the following in your local.conf:

<pre><nowiki>
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
</nowiki></pre>

(The last line is not required with version 2.5 and onwards as it is the default, but will do no harm.)

Once you have enabled buildhistory, you then need to build your image again so that buildhistory has a chance to record history data for it. Following that you can run <code>buildhistory-collect-srcrevs</code> (with <code>-a</code> if you want to see all revisions, not just the ones where AUTOREV was used) and it will output the revisions in a form you can use in a .inc file that you can <code>require</code> from your configuration if you want to fix the build to those revisions.

For more information see the [https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#maintaining-build-output-quality Maintaining Build Output Quality] section of the Yocto Project Development manual, which covers the buildhistory class in detail.

=== How do I do an offline build with recipes that have <code>SRCREV = "${AUTOREV}"</code> set? ===

If you set <code>BB_NO_NETWORK = "1"</code> and you have recipes that have <code>SRCREV = "${AUTOREV}"</code>, you will get an error because the build system will try to check the latest revision on startup and be immediately blocked by <code>BB_NO_NETWORK</code>. There are two ways to handle this:

A) See the previous question "How do I collect the source revisions fetched by each recipe?" and use the output generated by <code>buildhistory-collect-srcrevs</code> as a .inc file in your configuration in order to fix the revisions at the ones which were most recently built.

or

B) Set <code>BB_SRCREV_POLICY = "cache"</code> in your configuration. This will use the last cached revision. (The disadvantage of this method is that it is a little more difficult to preserve or share with others the fixed revisions.)

Note that in either case if you later want to build the latest version again, you will of course need to undo the configuration changes.

=== Is it possible to append a bbclass file (like bbappends do for recipes)? ===

No, see the next question for details.

=== How do I override a bbclass file? ===

This is tricky - bbclass files are found via BBPATH, which is added to by each layer.conf either by prepending or appending. Assuming you are putting your bbclass in a custom layer, you will probably want to have your layer's layer.conf prepend to BBPATH, but then you will also need to make sure that your layer does not appear before any other layer that is also prepending and overriding the same class.

Another alternative is to have an additional class which makes the appropriate changes to the environment, and then you will need to inherit that class after (and in the same manner as) the original class. This is slightly cleaner but can be annoying to enable particularly if the class is inherited by a number of recipes, and won't work if you want to alter the behaviour of a class inherited by recipes you don't control. (If you want a class to be inherited for all images (i.e. all recipes inheriting the <code>image</code> class) you can inject additional classes by setting IMAGE_CLASSES; similarly for the kernel there is KERNEL_CLASSES).

Ultimately, overriding bbclass files is not good practice long term - you are opening yourself up to maintenance issues when the original class changes, and the override is fragile as hinted above. The best solution is to try to get whatever changes you need into the original class; this does of course require additional work and time though.

=== There's a bbappend in a layer I'm using that defines a <code>do_something:append()</code> and I want to append to that function also, how do I do this? ===

Simply create a bbappend in your layer and define your own <code>do_something:append()</code>, and your commands will be executed ''as well as'' those of the other bbappend.

You might assume that defining <code>do_something:append()</code> will overwrite any previously defined <code>do_something:append()</code>, as would be the case with <code>do_something()</code> in the same situation, but that is not the case - the key is that <code>:append</code> (and <code>:prepend</code>, <code>:remove</code>, etc.) are ''operators'' and they will be applied in sequence, where that sequence is the order in which they are parsed (which for bbappends will be in ascending layer priority order).

YoctoProjectEvents

2023-12-23T19:27:13Z

Simonew: Update past events and add project summit

Traditionally, the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)
* a 1-day post-event DevDay
* a conference booth in the ELC/ELCE event hall, usually with demos

The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.

=== OE Developers Meeting ===
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc

== Yocto Project Summit ==
The Yocto Project Summit is a multiple day event and includes workshops and a forum where the current and future use of the Yocto Project can be discussed.

=== DevDay ===
DevDay was a 1-day training event consisting of multiple tracks:
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage
* hands-on classes based on narrow topics of a more specialized nature

== Events ==
Future events:
See also: https://www.yoctoproject.org/events/

Past events:
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_yps2023.11 Yocto Project Summit 2023.11]
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_yps2022.11 Yocto Project Summit 2022.11]
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_yps2022.05 Yocto Project Summit yps2022.05]
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]
* [https://wiki.yoctoproject.org/wiki/YP_Summit_Europe_2020 Yocto Project Summit Europe 2020]
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]
* [https://wiki.yoctoproject.org/wiki/YP_Summit_Lyon_2019 Yocto Project Summit Lyon 2019]
* [https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 OE Summit @ SCaLE 17x 2019]
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]

for a list of YP/OE-related talks at ELC/ELCE see:
* [https://elinux.org/Buildsystems https://elinux.org/Buildsystems]

Glossary of Terms and Acronyms

2023-12-20T15:59:52Z

Simonew: Remove release information, there is a sep. page for this. I will link it instead where appropriate

Back to Yocto Project [[Main Page]].

== Terminology ==
Here is a list of basic terms users new to the Yocto Project might find helpful. For a more complete list of terms, see the
"[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#yocto-project-terms Yocto Project Terms]" section in the Yocto Project Development Manual.
:'''Yocto Project''': A Linux Foundation project that acts as an umbrella for various efforts to improve Embedded Linux.
: '''OpenEmbedded''': The build system architecture promoted by the Yocto Project.
: '''BitBake''': A tool that reads metadata and runs tasks.
: '''OpenEmbedded-Core''': The common base set of metadata that BitBake uses. This metadata is shared between OpenEmbedded and the Yocto Project.
: '''Poky''': A reference distribution used for test and release purposes by the Yocto Project.
: '''Recipe''': Meta data defining how bitbake is to configure, build and package a software project.
: '''Layer''': A collection of recipes and/or configuration used by bitbake. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.

== Acronyms ==
:'''BSP''' Board Support Package
: '''CCB''' Change Control Board
: '''PMP''' Program Management Plan
: '''POR''' Plan of Record
: '''PRD''' Product Requirements Document

Main Page

2023-12-20T15:49:38Z

Simonew: Fix broken links, spelling

== Welcome to the Yocto Project Wiki! ==
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it's all about.

===Where to Start?===
If you're new to Yocto take a look at the '''[[Glossary]]''' so you're familiar with the terms used in this wiki and the project documentation. Then take a look at the [https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html '''Quick Start Guide''']. You can follow the steps in this document to clone the poky repository, quickly configure your build environment, and then try a build. Corporate firewalls can be problematic so network proxy configurations are detailed on the '''[[Working Behind a Network Proxy]]''' page. We advise you go straight for the [[Working_Behind_a_Network_Proxy#Option_2:_Chameleonsocks| Chameleonsocks option]].

===Where to Next?===
Thanks to the quick start guide, it's pretty easy to get your first Linux image build and running. Here are some places to look for help when improving your Yocto skills.
* The [https://linuxfoundation.org Linux Foundation] have some great [https://docs.google.com/presentation/d/1LmI3mHoD_Dzl8wplIYcUBrFF8BzDb_EadTvfbnpSK7Q/edit training slides]. There is also an [https://docs.google.com/presentation/d/1HoDtyN5SzlmuTN47ab4Y7w_i6c_VEW6EBUD944ntf38/edit#slide advanced slide deck] for more experienced users.
* The first tool you'll need to get familiar with is '''bitbake''', so reading through the [[https://docs.yoctoproject.org/dev/bitbake.htmluser manual] is recommended. You don't need to understand it all right now, but bookmark this page for reference. Implementation of bitake is covered in the [[Bitbake Internals Primer]]
* Once you start adding packages and configuring your image to create your own distribution, things can go wrong and it can hard to track down the root cause. There is no shortage of Yocto documentation resource, but if you're not exactly sure what you're looking for this '''[[Documentation Decoder]]''' will help you out. Also take a look at the [https://wiki.yoctoproject.org/wiki/Cookbook '''Cookbook'''] and [https://wiki.yoctoproject.org/wiki/Technical_FAQ troubleshooting guide]. Also [https://www.yoctoproject.org/community/learn/#books these books] are helpful.
* Some new tools such as [https://docs.yoctoproject.org/dev/toaster-manual/index.html Toaster], [[Extensible SDK]] and [https://github.com/crops CROPS] are making it easier to get the best out of Yocto on Windows and Mac OS X. Take a look at the new workflow in [[Developer Workflow Improvements]].
* There is also a [https://wiki.yoctoproject.org/wiki/TipsAndTricks '''Tips and Tricks'''] section where more experienced developers contribute to articles that will help those new to Yocto Project.
* You can also read and participate on the [https://lists.yoctoproject.org mailing lists] - start with the [https://lists.yoctoproject.org/g/yocto main list] first - and the IRC channel. More information about the Yocto Project mailing lists, IRC and Matrix channels can be found [https://www.yoctoproject.org/community/mailing-lists/ here].

== Project planning ==

=== Features ===
* [[Yocto Feature Summary]] (Current and Next)

=== Project Planning for current release ===

* [[Planning]]

=== Project Status and Schedule ===
* [[Weekly_Status]]
* Testresults - https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults

=== Future Directions ===
* [[Future_Directions]]

== Documentation ==

* [[Documentation Decoder]]

=== Improvement ideas ===

* [[Documentation Production Workflow]]

== Release Engineering ==

* [[Yocto Release Engineering | Yocto Project Release Engineering]]
* [[Yocto Release Engineering | Release Activity (with status, version info, QA links, etc)]]

== QA & Automation ==

* [[The_Yocto_Autobuilder| The Yocto Project Autobuilder]]
* [[QA| Yocto Project QA Main Page]]
* [[QA/Archive| Yocto Project QA Test Report Archive ]]

== Quick guide for newcomers ==

If you are new to the project and are willing to contribute, please refer to our [[Newcomers|guide for newcomers]].

== TSC ==
* Yocto Project Technical Steering Committee [[TSC]]

== Wiki reference sitemap ==
* [[Glossary]]
* [[Working Behind a Network Proxy]]
* [[FAQ]] and [[Technical FAQ]]. These need to be unified.
* [[Cookbook]] and [[TipsAndTricks | Tips and Tricks]]. Need clear messaging on how these should be differentiated.
* [[Developer Workflow Improvements]], including [[Nodejs Workflow Improvements]]
* [[Bug_Triage | Bug Triage Reference ]]
* [[Planning and Governance]]
* [[Community Guidelines]]
* [[Yocto Release Engineering | Yocto Project Release Engineering]]
* [[License Infrastructure Interest Group | License Infrastructure]]
* [[Processes and Activities]]
* [[Member Technical Contacts]]
* [[Projects]]
* [[Security]] - find out what we do about CVEs and security
* [[Yocto Interest Groups]]
* [[Toaster]] - the web interface
* [[YoctoProjectEvents]] - links to YoctoProject/OpenEmbedded related conferences and events
* [[Archive]] - Graveyard for out of date articles.

== Other resources ==
* [http://yoctoproject.org Yocto Project Front Page]
* [http://git.yoctoproject.org/ Yocto Project Git Source Repos]
* [https://docs.yoctoproject.org/ Yocto Project Documentation]
* [https://bugzilla.yoctoproject.org/ Yocto Project Bugzilla]
* [https://www.yoctoproject.org/tools-resources/community/mailing-lists Yocto Project Mailing Lists]
* [http://recipes.yoctoproject.org/rrs Yocto Project Recipe Reporting System]
* [https://autobuilder.yoctoproject.org/typhoon Yocto Project Autobuilder]
* [http://downloads.yoctoproject.org/releases/yocto/ Yocto Project Releases Downloads]
* [http://autobuilder.yoctoproject.org/pub/nightly/ Yocto Project Nightly Build Images]
* [http://downloads.yoctoproject.org/mirror/sources/ Upstream Sources Mirror]
* [http://www.openembedded.org/wiki/Main_Page OpenEmbedded Wiki]
* [http://cgit.openembedded.org/ OpenEmbedded Git Repos]
* [http://layers.openembedded.org/ OpenEmbedded Community Layers]
* [http://patchwork.openembedded.org/ OpenEmbedded Patch Tracking System]
* '''IRC''': [https://libera.chat/ irc.libera.chat]
:* #yocto - Public discussions on the Yocto Project.
:* #oe - Public discussions on OpenEmbedded Core.

User:Simonew

2023-12-20T15:33:15Z

Simonew:

I just started out to get involved upstream and want to use the opportunity - when I find stuff missing/outdated here - to add it directly.