build-appliance-image: Update to scarthgap head revision

(From OE-Core rev: cd2b6080a4c0f2ed2c9939ec0b87763aef595048)

Signed-off-by: Steve Sakoman <steve@sakoman.com>

bitbake/bin/bitbake-diffsigs

@@ -72,16 +72,17 @@ def find_siginfo_task(bbhandler, pn, taskname, sig1=None, sig2=None):
         elif sig2 not in sigfiles:
             logger.error('No sigdata files found matching %s %s with signature %s' % (pn, taskname, sig2))
             sys.exit(1)
+
+        latestfiles = [sigfiles[sig1]['path'], sigfiles[sig2]['path']]
     else:
         sigfiles = find_siginfo(bbhandler, pn, taskname)
         latestsigs = sorted(sigfiles.keys(), key=lambda h: sigfiles[h]['time'])[-2:]
         if not latestsigs:
             logger.error('No sigdata files found matching %s %s' % (pn, taskname))
             sys.exit(1)
-        sig1 = latestsigs[0]
-        sig2 = latestsigs[1]
-
-    latestfiles = [sigfiles[sig1]['path'], sigfiles[sig2]['path']]
+        latestfiles = [sigfiles[latestsigs[0]]['path']]
+        if len(latestsigs) > 1:
+            latestfiles.append(sigfiles[latestsigs[1]]['path'])
 
     return latestfiles
 

bitbake/lib/bb/data_smart.py

@@ -31,7 +31,7 @@ logger = logging.getLogger("BitBake.Data")
 
 __setvar_keyword__ = [":append", ":prepend", ":remove"]
 __setvar_regexp__ = re.compile(r'(?P<base>.*?)(?P<keyword>:append|:prepend|:remove)(:(?P<add>[^A-Z]*))?$')
-__expand_var_regexp__ = re.compile(r"\${[a-zA-Z0-9\-_+./~:]+?}")
+__expand_var_regexp__ = re.compile(r"\${[a-zA-Z0-9\-_+./~:]+}")
 __expand_python_regexp__ = re.compile(r"\${@(?:{.*?}|.)+?}")
 __whitespace_split__ = re.compile(r'(\s)')
 __override_regexp__ = re.compile(r'[a-z0-9]+')
@@ -580,12 +580,9 @@ class DataSmart(MutableMapping):
             else:
                 loginfo['op'] = keyword
             self.varhistory.record(**loginfo)
-            # todo make sure keyword is not __doc__ or __module__
-            # pay the cookie monster
 
             # more cookies for the cookie monster
-            if ':' in var:
-                self._setvar_update_overrides(base, **loginfo)
+            self._setvar_update_overrides(base, **loginfo)
 
             if base in self.overridevars:
                 self._setvar_update_overridevars(var, value)
@@ -638,6 +635,7 @@ class DataSmart(MutableMapping):
                 nextnew.update(vardata.contains.keys())
             new = nextnew
         self.overrides = None
+        self.expand_cache = {}
 
     def _setvar_update_overrides(self, var, **loginfo):
         # aka pay the cookie monster

bitbake/lib/bblayers/query.py

@@ -145,7 +145,8 @@ skipped recipes will also be listed, with a " (skipped)" suffix.
         skiplist = list(self.tinfoil.cooker.skiplist_by_mc[mc].keys())
 
         if mc:
-            skiplist = [s.removeprefix(f'mc:{mc}:') for s in skiplist]
+            mcspec = f'mc:{mc}:'
+            skiplist = [s[len(mcspec):] if s.startswith(mcspec) else s for s in skiplist]
 
         for fn in skiplist:
             recipe_parts = os.path.splitext(os.path.basename(fn))[0].split('_')

documentation/conf.py

@@ -136,6 +136,7 @@ except ImportError:
     sys.exit(1)
 
 html_logo = 'sphinx-static/YoctoProject_Logo_RGB.jpg'
+html_favicon = 'sphinx-static/favicon.ico'
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,

documentation/contributor-guide/submit-changes.rst

@@ -832,3 +832,52 @@ Other layers may have similar testing branches but there is no formal
 requirement or standard for these so please check the documentation for the
 layers you are contributing to.
 
+Acceptance of AI Generated Code
+===============================
+
+The Yocto Project and OpenEmbedded follow the guidance of the Linux Foundation
+in regards to the use of generative AI tools. See:
+https://www.linuxfoundation.org/legal/generative-ai.
+
+All of the existing guidelines in this document are expected to be followed,
+including in the :doc:`recipe-style-guide`, and contributing the changes with
+additional requirements to the items in section
+:ref:`contributor-guide/submit-changes:Implement and commit changes`.
+
+All AI Generated Code must be labeled as such in the commit message,
+prior to your ``Signed-off-by`` line. It is also strongly recommended,
+that any patches or code within the commit also have a comment or other
+indication that this code was AI generated.
+
+For example, here is a properly formatted commit message::
+
+   component: Add the ability to ...
+
+   AI-Generated: Uses GitHub Copilot
+
+   Signed-off-by: Your Name <your.name@domain>
+
+The ``Signed-off-by`` line must be written by you, and not the AI helper.
+As a reminder, when contributing a change, your ``Signed-off-by`` line is
+required and the stipulations in the `Developer's Statement of Origin
+1.1 <https://developercertificate.org/>`__ still apply.
+
+Additionally, you must stipulate AI contributions conform to the Linux
+Foundation policy, specifically:
+
+#. Contributors should ensure that the terms and conditions of the generative AI
+   tool do not place any contractual restrictions on how the tool's output can
+   be used that are inconsistent with the project's open source software
+   license, the project's intellectual property policies, or the Open Source
+   Definition.
+
+#. If any pre-existing copyrighted materials (including pre-existing open
+   source code) authored or owned by third parties are included in the AI tool's
+   output, prior to contributing such output to the project, the Contributor
+   should confirm that they have permission from the third party
+   owners -- such as the form of an open source license or public domain
+   declaration that complies with the project's licensing policies -- to use and
+   modify such pre-existing materials and contribute them to the project.
+   Additionally, the contributor should provide notice and attribution of such
+   third party rights, along with information about the applicable license
+   terms, with their contribution.

documentation/dev-manual/building.rst

@@ -280,7 +280,9 @@ Follow these steps to create an :term:`Initramfs` image:
 #. *Create the Initramfs Image Recipe:* You can reference the
    ``core-image-minimal-initramfs.bb`` recipe found in the
    ``meta/recipes-core`` directory of the :term:`Source Directory`
-   as an example from which to work.
+   as an example from which to work. The ``core-image-minimal-initramfs`` recipe
+   is based on the :ref:`initramfs-framework <dev-manual/building:Customizing an
+   Initramfs using \`\`initramfs-framework\`\`>` recipe described below.
 
 #. *Decide if You Need to Bundle the Initramfs Image Into the Kernel
    Image:* If you want the :term:`Initramfs` image that is built to be bundled
@@ -308,6 +310,86 @@ Follow these steps to create an :term:`Initramfs` image:
    and bundled with the kernel image if you used the
    :term:`INITRAMFS_IMAGE_BUNDLE` variable described earlier.
 
+Customizing an Initramfs using ``initramfs-framework``
+------------------------------------------------------
+
+The ``core-image-minimal-initramfs.bb`` recipe found in
+:oe_git:`meta/recipes-core/images
+</openembedded-core/tree/meta/recipes-core/images>` uses the
+:oe_git:`initramfs-framework_1.0.bb
+</openembedded-core/tree/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb>`
+recipe as its base component. The goal of the ``initramfs-framework`` recipe is
+to provide the building blocks to build a customized :term:`Initramfs`.
+
+The ``initramfs-framework`` recipe relies on shell initialization scripts
+defined in :oe_git:`meta/recipes-core/initrdscripts/initramfs-framework
+</openembedded-core/tree/meta/recipes-core/initrdscripts/initramfs-framework>`. Since some of
+these scripts do not apply for all use cases, the ``initramfs-framework`` recipe
+defines different packages:
+
+-  ``initramfs-framework-base``: this package installs the basic components of
+   an :term:`Initramfs`, such as the ``init`` script or the ``/dev/console``
+   character special file. As this package is a runtime dependency of all
+   modules listed below, it is automatically pulled in when one of the modules
+   is installed in the image.
+-  ``initramfs-module-exec``: support for execution of applications.
+-  ``initramfs-module-mdev``: support for `mdev
+   <https://wiki.gentoo.org/wiki/Mdev>`__.
+-  ``initramfs-module-udev``: support for :wikipedia:`Udev <Udev>`.
+-  ``initramfs-module-e2fs``: support for :wikipedia:`ext4/ext3/ext2
+   <Extended_file_system>` filesystems.
+-  ``initramfs-module-nfsrootfs``: support for locating and mounting the root
+   partition via :wikipedia:`NFS <Network_File_System>`.
+-  ``initramfs-module-rootfs``: support for locating and mounting the root
+   partition.
+-  ``initramfs-module-debug``: dynamic debug support.
+-  ``initramfs-module-lvm``: :wikipedia:`LVM <Logical_volume_management>` rootfs support.
+-  ``initramfs-module-overlayroot``: support for mounting a read-write overlay
+   on top of a read-only root filesystem.
+
+In addition to the packages defined by the ``initramfs-framework`` recipe
+itself, the following packages are defined by the recipes present in
+:oe_git:`meta/recipes-core/initrdscripts </openembedded-core/tree/meta/recipes-core/initrdscripts>`:
+
+-  ``initramfs-module-install``: module to create and install a partition layout
+   on a selected block device.
+-  ``initramfs-module-install-efi``: module to create and install an EFI
+   partition layout on a selected block device.
+-  ``initramfs-module-setup-live``: module to start a shell in the
+   :term:`Initramfs` if ``root=/dev/ram0`` in passed in the `Kernel command-line
+   <https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html>`__
+   or the ``root=`` parameter was not passed.
+
+To customize the :term:`Initramfs`, you can add or remove packages listed
+earlier from the :term:`PACKAGE_INSTALL` variable with a :ref:`bbappend
+<dev-manual/layers:Appending Other Layers Metadata With Your Layer>` on the
+``core-image-minimal-initramfs`` recipe, or create a custom recipe for the
+:term:`Initramfs` taking ``core-image-minimal-initramfs`` as example.
+
+Custom scripts can be added to the :term:`Initramfs` by writing your own
+recipes. The recipes are conventionally named ``initramfs-module-<module name>``
+where ``<module name>`` is the name of the module. The recipe should set its
+:term:`RDEPENDS` package-specific variables to include
+``initramfs-framework-base`` and the other packages on which the module depends
+at runtime.
+
+The recipe must install shell initialization scripts in :term:`${D} <D>`\
+``/init.d`` and must follow the ``<number>-<script name>`` naming scheme where:
+
+-  ``<number>`` is a *two-digit* number that affects the execution order of the
+   script compared to others. For example, the script ``80-setup-live`` would be
+   executed after ``01-udev`` because 80 is greater than 01.
+
+   This number being two-digits is important here as the scripts are executed
+   alphabetically. For example, the script ``10-script`` would be executed
+   before the script ``8-script``, because ``1`` is inferior to ``8``.
+   Therefore, the script should be named ``08-script``.
+
+-  ``<script name>`` is the script name which you can choose freely.
+
+   If two script use the same ``<number>``, they are sorted alphabetically based
+   on ``<script name>``.
+
 Bundling an Initramfs Image From a Separate Multiconfig
 -------------------------------------------------------
 

documentation/dev-manual/customizing-images.rst

@@ -80,15 +80,14 @@ recipe that are enabled with :term:`IMAGE_FEATURES`. The value of
 :term:`EXTRA_IMAGE_FEATURES` is added to :term:`IMAGE_FEATURES` within
 ``meta/conf/bitbake.conf``.
 
-To illustrate how you can use these variables to modify your image,
-consider an example that selects the SSH server. The Yocto Project ships
-with two SSH servers you can use with your images: Dropbear and OpenSSH.
-Dropbear is a minimal SSH server appropriate for resource-constrained
-environments, while OpenSSH is a well-known standard SSH server
-implementation. By default, the ``core-image-sato`` image is configured
-to use Dropbear. The ``core-image-full-cmdline`` and ``core-image-lsb``
-images both include OpenSSH. The ``core-image-minimal`` image does not
-contain an SSH server.
+To illustrate how you can use these variables to modify your image, consider an
+example that selects the SSH server. The Yocto Project ships with two SSH
+servers you can use with your images: Dropbear and OpenSSH. Dropbear is a
+minimal SSH server appropriate for resource-constrained environments, while
+OpenSSH is a well-known standard SSH server implementation. By default, the
+``core-image-sato`` image is configured to use Dropbear. The
+``core-image-full-cmdline`` image includes OpenSSH. The ``core-image-minimal``
+image does not contain an SSH server.
 
 You can customize your image and change these defaults. Edit the
 :term:`IMAGE_FEATURES` variable in your recipe or use the

documentation/dev-manual/qemu.rst

@@ -280,12 +280,11 @@ present, the toolchain is also automatically used.
       networking.
 
    -  SSH servers are available in some QEMU images. The ``core-image-sato``
-      QEMU image has a Dropbear secure shell (SSH) server that runs with
-      the root password disabled. The ``core-image-full-cmdline`` and
-      ``core-image-lsb`` QEMU images have OpenSSH instead of Dropbear.
-      Including these SSH servers allow you to use standard ``ssh`` and
-      ``scp`` commands. The ``core-image-minimal`` QEMU image, however,
-      contains no SSH server.
+      QEMU image has a Dropbear secure shell (SSH) server that runs with the
+      root password disabled. The ``core-image-full-cmdline`` QEMU image has
+      OpenSSH instead of Dropbear. Including these SSH servers allow you to use
+      standard ``ssh`` and ``scp`` commands. The ``core-image-minimal`` QEMU
+      image, however, contains no SSH server.
 
    -  You can use a provided, user-space NFS server to boot the QEMU
       session using a local copy of the root filesystem on the host. In

documentation/dev-manual/vulnerabilities.rst

@@ -62,37 +62,77 @@ found in ``build/tmp/deploy/cve``.
 
 For example the CVE check report for the ``flex-native`` recipe looks like::
 
-   $ cat poky/build/tmp/deploy/cve/flex-native
-   LAYER: meta
-   PACKAGE NAME: flex-native
-   PACKAGE VERSION: 2.6.4
-   CVE: CVE-2016-6354
-   CVE STATUS: Patched
-   CVE SUMMARY: Heap-based buffer overflow in the yy_get_next_buffer function in Flex before 2.6.1 might allow context-dependent attackers to cause a denial of service or possibly execute arbitrary code via vectors involving num_to_read.
-   CVSS v2 BASE SCORE: 7.5
-   CVSS v3 BASE SCORE: 9.8
-   VECTOR: NETWORK
-   MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-6354
-
-   LAYER: meta
-   PACKAGE NAME: flex-native
-   PACKAGE VERSION: 2.6.4
-   CVE: CVE-2019-6293
-   CVE STATUS: Ignored
-   CVE SUMMARY: An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.
-   CVSS v2 BASE SCORE: 4.3
-   CVSS v3 BASE SCORE: 5.5
-   VECTOR: NETWORK
-   MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2019-6293
+   $ cat ./tmp/deploy/cve/flex-native_cve.json
+   {
+     "version": "1",
+     "package": [
+       {
+         "name": "flex-native",
+         "layer": "meta",
+         "version": "2.6.4",
+         "products": [
+           {
+             "product": "flex",
+             "cvesInRecord": "No"
+           },
+           {
+             "product": "flex",
+             "cvesInRecord": "Yes"
+           }
+         ],
+         "issue": [
+           {
+             "id": "CVE-2006-0459",
+             "status": "Patched",
+             "link": "https://nvd.nist.gov/vuln/detail/CVE-2006-0459",
+             "summary": "flex.skl in Will Estes and John Millaway Fast Lexical Analyzer Generator (flex) before 2.5.33 does not allocate enough memory for grammars containing (1) REJECT statements or (2) trailing context rules, which causes flex to generate code that contains a buffer overflow that might allow context-dependent attackers to execute arbitrary code.",
+             "scorev2": "7.5",
+             "scorev3": "0.0",
+             "scorev4": "0.0",
+             "modified": "2024-11-21T00:06Z",
+             "vector": "NETWORK",
+             "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P",
+             "detail": "version-not-in-range"
+           },
+           {
+             "id": "CVE-2016-6354",
+             "status": "Patched",
+             "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-6354",
+             "summary": "Heap-based buffer overflow in the yy_get_next_buffer function in Flex before 2.6.1 might allow context-dependent attackers to cause a denial of service or possibly execute arbitrary code via vectors involving num_to_read.",
+             "scorev2": "7.5",
+             "scorev3": "9.8",
+             "scorev4": "0.0",
+             "modified": "2024-11-21T02:55Z",
+             "vector": "NETWORK",
+             "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P",
+             "detail": "version-not-in-range"
+           },
+           {
+             "id": "CVE-2019-6293",
+             "status": "Ignored",
+             "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-6293",
+             "summary": "An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.",
+             "scorev2": "4.3",
+             "scorev3": "5.5",
+             "scorev4": "0.0",
+             "modified": "2024-11-21T04:46Z",
+             "vector": "NETWORK",
+             "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P",
+             "detail": "upstream-wontfix",
+             "description": "there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address this."
+           }
+         ]
+       }
+     ]
+   }
 
 For images, a summary of all recipes included in the image and their CVEs is also
-generated in textual and JSON formats. These ``.cve`` and ``.json`` reports can be found
+generated in the JSON format. These ``.json`` reports can be found
 in the ``tmp/deploy/images`` directory for each compiled image.
 
 At build time CVE check will also throw warnings about ``Unpatched`` CVEs::
 
-   WARNING: flex-2.6.4-r0 do_cve_check: Found unpatched CVE (CVE-2019-6293), for more information check /poky/build/tmp/work/core2-64-poky-linux/flex/2.6.4-r0/temp/cve.log
-   WARNING: libarchive-3.5.1-r0 do_cve_check: Found unpatched CVE (CVE-2021-36976), for more information check /poky/build/tmp/work/core2-64-poky-linux/libarchive/3.5.1-r0/temp/cve.log
+   WARNING: qemu-native-9.2.0-r0 do_cve_check: Found unpatched CVE (CVE-2023-1386)
 
 It is also possible to check the CVE status of individual packages as follows::
 
@@ -111,10 +151,10 @@ upstream `NIST CVE database <https://nvd.nist.gov/>`__.
 
 The variable supports using vendor and product names like this::
 
-   CVE_PRODUCT = "flex_project:flex"
+   CVE_PRODUCT = "flex_project:flex westes:flex"
 
-In this example the vendor name used in the CVE database is ``flex_project`` and the
-product is ``flex``. With this setting the ``flex`` recipe only maps to this specific
+In this example we have two possible vendors names,  ``flex_project`` and ``westes``,
+with the product name ``flex``. With this setting the ``flex`` recipe only maps to this specific
 product and not products from other vendors with same name ``flex``.
 
 Similarly, when the recipe version :term:`PV` is not compatible with software versions used by

documentation/migration-guides/release-4.0.rst

@@ -30,4 +30,5 @@ Release 4.0 (kirkstone)
    release-notes-4.0.21
    release-notes-4.0.22
    release-notes-4.0.23
-
+   release-notes-4.0.24
+   release-notes-4.0.25

documentation/migration-guides/release-5.0.rst

@@ -13,3 +13,5 @@ Release 5.0 (scarthgap)
    release-notes-5.0.4
    release-notes-5.0.5
    release-notes-5.0.6
+   release-notes-5.0.7
+

documentation/migration-guides/release-notes-4.0.24.rst

@@ -0,0 +1,383 @@
+Release notes for Yocto-4.0.24 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  coreutils: Fix :cve_nist:`2024-0684`
+-  cpio: Ignore :cve_nist:`2023-7216`
+-  diffoscope: Fix :cve_nist:`2024-25711`
+-  ffmpeg: fix :cve_mitre:`2023-47342`, :cve_nist:`2023-50007`, :cve_nist:`2023-50008`,
+   :cve_nist:`2023-51793`, :cve_nist:`2023-51794`, :cve_nist:`2023-51796`, :cve_nist:`2023-51798`,
+   :cve_nist:`2024-7055`, :cve_nist:`2024-31578`, :cve_nist:`2024-31582`, :cve_nist:`2024-32230`,
+   :cve_nist:`2024-35366`, :cve_nist:`2024-35367` and :cve_nist:`2024-35368`
+-  ghostscript: Fix :cve_nist:`2024-46951`, :cve_nist:`2024-46952`, :cve_nist:`2024-46953`,
+   :cve_nist:`2024-46955` and :cve_nist:`2024-46956`
+-  ghostscript: Ignore :cve_nist:`2024-46954`
+-  glib-2.0: Fix :cve_nist:`2024-52533`
+-  gnupg: Ignore :cve_nist:`2022-3515`
+-  grub: Ignore :cve_nist:`2024-1048` and :cve_nist:`2023-4001`
+-  gstreame1.0: Ignore :cve_nist:`2023-40474`, :cve_nist:`2023-40475`, :cve_nist:`2023-40476`,
+   :cve_nist:`2023-44429`, :cve_nist:`2023-44446`, :cve_nist:`2023-50186` and :cve_nist:`2024-0444`
+-  gstreamer1.0-plugins-base: Fix :cve_nist:`2024-47538`, :cve_nist:`2024-47541`,
+   :cve_nist:`2024-47542`, :cve_nist:`2024-47600`, :cve_nist:`2024-47607`, :cve_nist:`2024-47615`
+   and :cve_nist:`2024-47835`
+-  gstreamer1.0-plugins-good: Fix :cve_nist:`2024-47537`, :cve_nist:`2024-47539`,
+   :cve_nist:`2024-47540`, :cve_nist:`2024-47543`, :cve_nist:`2024-47544`, :cve_nist:`2024-47545`,
+   :cve_nist:`2024-47546`, :cve_nist:`2024-47596`, :cve_nist:`2024-47597`, :cve_nist:`2024-47598`,
+   :cve_nist:`2024-47599`, :cve_nist:`2024-47601`, :cve_nist:`2024-47602`, :cve_nist:`2024-47603`,
+   :cve_nist:`2024-47606`, :cve_nist:`2024-47613`, :cve_nist:`2024-47774`, :cve_nist:`2024-47775`,
+   :cve_nist:`2024-47776`, :cve_nist:`2024-47777`, :cve_nist:`2024-47778` and :cve_nist:`2024-47834`
+-  gstreamer1.0: Fix :cve_nist:`2024-47606`
+-  libarchive: Fix :cve_nist:`2024-20696`
+-  libpam: Fix :cve_nist:`2024-10041`
+-  libsdl2: Ignore :cve_nist:`2020-14409` and :cve_nist:`2020-14410`
+-  libsndfile1: Fix :cve_nist:`2022-33065` and :cve_nist:`2024-50612`
+-  libsoup-2.4: Fix :cve_nist:`2024-52530`, :cve_nist:`2024-52531` and :cve_nist:`2024-52532`
+-  libsoup: Fix :cve_nist:`2024-52530`, :cve_nist:`2024-52531` and :cve_nist:`2024-52532`
+-  linux-yocto/5.10: Fix :cve_nist:`2023-52889`, :cve_nist:`2023-52917`, :cve_nist:`2023-52918`,
+   :cve_nist:`2024-41011`, :cve_nist:`2024-42259`, :cve_nist:`2024-42271`, :cve_nist:`2024-42272`,
+   :cve_nist:`2024-42280`, :cve_nist:`2024-42283`, :cve_nist:`2024-42284`, :cve_nist:`2024-42285`,
+   :cve_nist:`2024-42286`, :cve_nist:`2024-42287`, :cve_nist:`2024-42288`, :cve_nist:`2024-42289`,
+   :cve_nist:`2024-42301`, :cve_nist:`2024-42302`, :cve_nist:`2024-42309`, :cve_nist:`2024-42310`,
+   :cve_nist:`2024-42311`, :cve_nist:`2024-42313`, :cve_nist:`2024-43828`, :cve_nist:`2024-43856`,
+   :cve_nist:`2024-43858`, :cve_nist:`2024-43860`, :cve_nist:`2024-43861`, :cve_nist:`2024-43871`,
+   :cve_nist:`2024-43882`, :cve_nist:`2024-43889`, :cve_nist:`2024-43890`, :cve_nist:`2024-43893`,
+   :cve_nist:`2024-43894`, :cve_nist:`2024-43907`, :cve_nist:`2024-43908`, :cve_nist:`2024-43914`,
+   :cve_nist:`2024-44935`, :cve_nist:`2024-44944`, :cve_nist:`2024-44947`, :cve_nist:`2024-44954`,
+   :cve_nist:`2024-44960`, :cve_nist:`2024-44965`, :cve_nist:`2024-44969`, :cve_nist:`2024-44971`,
+   :cve_nist:`2024-44987`, :cve_nist:`2024-44988`, :cve_nist:`2024-44989`, :cve_nist:`2024-44990`,
+   :cve_nist:`2024-44995`, :cve_nist:`2024-44998`, :cve_nist:`2024-44999`, :cve_nist:`2024-45003`,
+   :cve_nist:`2024-45006`, :cve_nist:`2024-45016`, :cve_nist:`2024-45018`, :cve_nist:`2024-45021`,
+   :cve_nist:`2024-45025`, :cve_nist:`2024-45026`, :cve_nist:`2024-45028`, :cve_nist:`2024-46673`,
+   :cve_nist:`2024-46674`, :cve_nist:`2024-46675`, :cve_nist:`2024-46676`, :cve_nist:`2024-46677`,
+   :cve_nist:`2024-46679`, :cve_nist:`2024-46685`, :cve_nist:`2024-46689`, :cve_nist:`2024-46702`,
+   :cve_nist:`2024-46707`, :cve_nist:`2024-46714`, :cve_nist:`2024-46719`, :cve_nist:`2024-46721`,
+   :cve_nist:`2024-46722`, :cve_nist:`2024-46723`, :cve_nist:`2024-46724`, :cve_nist:`2024-46725`,
+   :cve_nist:`2024-46731`, :cve_nist:`2024-46737`, :cve_nist:`2024-46738`, :cve_nist:`2024-46739`,
+   :cve_nist:`2024-46740`, :cve_nist:`2024-46743`, :cve_nist:`2024-46744`, :cve_nist:`2024-46747`,
+   :cve_nist:`2024-46750`, :cve_nist:`2024-46755`, :cve_nist:`2024-46759`, :cve_nist:`2024-46761`,
+   :cve_nist:`2024-46763`, :cve_nist:`2024-46771`, :cve_nist:`2024-46777`, :cve_nist:`2024-46780`,
+   :cve_nist:`2024-46781`, :cve_nist:`2024-46782`, :cve_nist:`2024-46783`, :cve_nist:`2024-46791`,
+   :cve_nist:`2024-46798`, :cve_nist:`2024-46800`, :cve_nist:`2024-46804`, :cve_nist:`2024-46814`,
+   :cve_nist:`2024-46815`, :cve_nist:`2024-46817`, :cve_nist:`2024-46818`, :cve_nist:`2024-46819`,
+   :cve_nist:`2024-46822`, :cve_nist:`2024-46828`, :cve_nist:`2024-46829`, :cve_nist:`2024-46832`,
+   :cve_nist:`2024-46840`, :cve_nist:`2024-46844`, :cve_nist:`2024-47659`, :cve_nist:`2024-47660`,
+   :cve_nist:`2024-47663`, :cve_nist:`2024-47667`, :cve_nist:`2024-47668`, :cve_nist:`2024-47669`,
+   :cve_nist:`2024-47679`, :cve_nist:`2024-47684`, :cve_nist:`2024-47685`, :cve_nist:`2024-47692`,
+   :cve_nist:`2024-47697`, :cve_nist:`2024-47698`, :cve_nist:`2024-47699`, :cve_nist:`2024-47701`,
+   :cve_nist:`2024-47705`, :cve_nist:`2024-47706`, :cve_nist:`2024-47710`, :cve_nist:`2024-47712`,
+   :cve_nist:`2024-47713`, :cve_nist:`2024-47718`, :cve_nist:`2024-47723`, :cve_nist:`2024-47735`,
+   :cve_nist:`2024-47737`, :cve_nist:`2024-47739`, :cve_nist:`2024-47742`, :cve_nist:`2024-47747`,
+   :cve_nist:`2024-47748`, :cve_nist:`2024-47749`, :cve_nist:`2024-47757`, :cve_nist:`2024-49851`,
+   :cve_nist:`2024-49858`, :cve_nist:`2024-49860`, :cve_nist:`2024-49863`, :cve_nist:`2024-49867`,
+   :cve_nist:`2024-49868`, :cve_nist:`2024-49875`, :cve_nist:`2024-49877`, :cve_nist:`2024-49878`,
+   :cve_nist:`2024-49879`, :cve_nist:`2024-49881`, :cve_nist:`2024-49882`, :cve_nist:`2024-49883`,
+   :cve_nist:`2024-49884`, :cve_nist:`2024-49889`, :cve_nist:`2024-49890`, :cve_nist:`2024-49892`,
+   :cve_nist:`2024-49894`, :cve_nist:`2024-49895`, :cve_nist:`2024-49896`, :cve_nist:`2024-49900`,
+   :cve_nist:`2024-49902`, :cve_nist:`2024-49903`, :cve_nist:`2024-49907`, :cve_nist:`2024-49913`,
+   :cve_nist:`2024-49924`, :cve_nist:`2024-49930`, :cve_nist:`2024-49933`, :cve_nist:`2024-49936`,
+   :cve_nist:`2024-49938`, :cve_nist:`2024-49944`, :cve_nist:`2024-49948`, :cve_nist:`2024-49949`,
+   :cve_nist:`2024-49952`, :cve_nist:`2024-49955`, :cve_nist:`2024-49957`, :cve_nist:`2024-49958`,
+   :cve_nist:`2024-49959`, :cve_nist:`2024-49962`, :cve_nist:`2024-49963`, :cve_nist:`2024-49965`,
+   :cve_nist:`2024-49966`, :cve_nist:`2024-49969`, :cve_nist:`2024-49973`, :cve_nist:`2024-49975`,
+   :cve_nist:`2024-49977`, :cve_nist:`2024-49981`, :cve_nist:`2024-49982`, :cve_nist:`2024-49983`,
+   :cve_nist:`2024-49985`, :cve_nist:`2024-49995`, :cve_nist:`2024-49997`, :cve_nist:`2024-50001`,
+   :cve_nist:`2024-50006`, :cve_nist:`2024-50007`, :cve_nist:`2024-50008`, :cve_nist:`2024-50013`,
+   :cve_nist:`2024-50015`, :cve_nist:`2024-50024`, :cve_nist:`2024-50033`, :cve_nist:`2024-50035`,
+   :cve_nist:`2024-50039`, :cve_nist:`2024-50040`, :cve_nist:`2024-50044`, :cve_nist:`2024-50045`,
+   :cve_nist:`2024-50046`, :cve_nist:`2024-50049`, :cve_nist:`2024-50059`, :cve_nist:`2024-50095`,
+   :cve_nist:`2024-50096`, :cve_nist:`2024-50179`, :cve_nist:`2024-50180`, :cve_nist:`2024-50181`,
+   :cve_nist:`2024-50184` and :cve_nist:`2024-50188`
+-  linux-yocto/5.15: Fix :cve_nist:`2022-48695`, :cve_nist:`2023-52530`, :cve_nist:`2023-52917`,
+   :cve_nist:`2024-45009`, :cve_nist:`2024-46714`, :cve_nist:`2024-46719`, :cve_nist:`2024-46721`,
+   :cve_nist:`2024-46722`, :cve_nist:`2024-46723`, :cve_nist:`2024-46724`, :cve_nist:`2024-46725`,
+   :cve_nist:`2024-46731`, :cve_nist:`2024-46732`, :cve_nist:`2024-46737`, :cve_nist:`2024-46738`,
+   :cve_nist:`2024-46739`, :cve_nist:`2024-46740`, :cve_nist:`2024-46743`, :cve_nist:`2024-46744`,
+   :cve_nist:`2024-46746`, :cve_nist:`2024-46747`, :cve_nist:`2024-46750`, :cve_nist:`2024-46755`,
+   :cve_nist:`2024-46759`, :cve_nist:`2024-46761`, :cve_nist:`2024-46763`, :cve_nist:`2024-46771`,
+   :cve_nist:`2024-46777`, :cve_nist:`2024-46780`, :cve_nist:`2024-46781`, :cve_nist:`2024-46782`,
+   :cve_nist:`2024-46783`, :cve_nist:`2024-46791`, :cve_nist:`2024-46795`, :cve_nist:`2024-46798`,
+   :cve_nist:`2024-46800`, :cve_nist:`2024-46804`, :cve_nist:`2024-46805`, :cve_nist:`2024-46807`,
+   :cve_nist:`2024-46810`, :cve_nist:`2024-46814`, :cve_nist:`2024-46815`, :cve_nist:`2024-46817`,
+   :cve_nist:`2024-46818`, :cve_nist:`2024-46819`, :cve_nist:`2024-46822`, :cve_nist:`2024-46828`,
+   :cve_nist:`2024-46829`, :cve_nist:`2024-46832`, :cve_nist:`2024-46840`, :cve_nist:`2024-46844`,
+   :cve_nist:`2024-47659`, :cve_nist:`2024-47660`, :cve_nist:`2024-47663`, :cve_nist:`2024-47665`,
+   :cve_nist:`2024-47667`, :cve_nist:`2024-47668`, :cve_nist:`2024-47669`, :cve_nist:`2024-47674`,
+   :cve_nist:`2024-47679`, :cve_nist:`2024-47684`, :cve_nist:`2024-47685`, :cve_nist:`2024-47690`,
+   :cve_nist:`2024-47692`, :cve_nist:`2024-47693`, :cve_nist:`2024-47695`, :cve_nist:`2024-47696`,
+   :cve_nist:`2024-47697`, :cve_nist:`2024-47698`, :cve_nist:`2024-47699`, :cve_nist:`2024-47701`,
+   :cve_nist:`2024-47705`, :cve_nist:`2024-47706`, :cve_nist:`2024-47710`, :cve_nist:`2024-47712`,
+   :cve_nist:`2024-47713`, :cve_nist:`2024-47718`, :cve_nist:`2024-47720`, :cve_nist:`2024-47723`,
+   :cve_nist:`2024-47734`, :cve_nist:`2024-47735`, :cve_nist:`2024-47737`, :cve_nist:`2024-47739`,
+   :cve_nist:`2024-47742`, :cve_nist:`2024-47747`, :cve_nist:`2024-47748`, :cve_nist:`2024-47749`,
+   :cve_nist:`2024-47757`, :cve_nist:`2024-49851`, :cve_nist:`2024-49852`, :cve_nist:`2024-49854`,
+   :cve_nist:`2024-49856`, :cve_nist:`2024-49858`, :cve_nist:`2024-49860`, :cve_nist:`2024-49863`,
+   :cve_nist:`2024-49866`, :cve_nist:`2024-49867`, :cve_nist:`2024-49868`, :cve_nist:`2024-49871`,
+   :cve_nist:`2024-49875`, :cve_nist:`2024-49877`, :cve_nist:`2024-49878`, :cve_nist:`2024-49879`,
+   :cve_nist:`2024-49881`, :cve_nist:`2024-49882`, :cve_nist:`2024-49883`, :cve_nist:`2024-49884`,
+   :cve_nist:`2024-49886`, :cve_nist:`2024-49889`, :cve_nist:`2024-49890`, :cve_nist:`2024-49892`,
+   :cve_nist:`2024-49894`, :cve_nist:`2024-49895`, :cve_nist:`2024-49896`, :cve_nist:`2024-49900`,
+   :cve_nist:`2024-49902`, :cve_nist:`2024-49903`, :cve_nist:`2024-49907`, :cve_nist:`2024-49913`,
+   :cve_nist:`2024-49924`, :cve_nist:`2024-49927`, :cve_nist:`2024-49930`, :cve_nist:`2024-49933`,
+   :cve_nist:`2024-49935`, :cve_nist:`2024-49936`, :cve_nist:`2024-49938`, :cve_nist:`2024-49944`,
+   :cve_nist:`2024-49946`, :cve_nist:`2024-49948`, :cve_nist:`2024-49949`, :cve_nist:`2024-49952`,
+   :cve_nist:`2024-49954`, :cve_nist:`2024-49955`, :cve_nist:`2024-49957`, :cve_nist:`2024-49958`,
+   :cve_nist:`2024-49959`, :cve_nist:`2024-49962`, :cve_nist:`2024-49963`, :cve_nist:`2024-49965`,
+   :cve_nist:`2024-49966`, :cve_nist:`2024-49969`, :cve_nist:`2024-49973`, :cve_nist:`2024-49975`,
+   :cve_nist:`2024-49977`, :cve_nist:`2024-49981`, :cve_nist:`2024-49982`, :cve_nist:`2024-49983`,
+   :cve_nist:`2024-49985`, :cve_nist:`2024-49995`, :cve_nist:`2024-49997`, :cve_nist:`2024-50000`,
+   :cve_nist:`2024-50001`, :cve_nist:`2024-50002`, :cve_nist:`2024-50003`, :cve_nist:`2024-50006`,
+   :cve_nist:`2024-50007`, :cve_nist:`2024-50008`, :cve_nist:`2024-50013`, :cve_nist:`2024-50015`,
+   :cve_nist:`2024-50019`, :cve_nist:`2024-50024`, :cve_nist:`2024-50031`, :cve_nist:`2024-50033`,
+   :cve_nist:`2024-50035`, :cve_nist:`2024-50038`, :cve_nist:`2024-50039`, :cve_nist:`2024-50040`,
+   :cve_nist:`2024-50041`, :cve_nist:`2024-50044`, :cve_nist:`2024-50045`, :cve_nist:`2024-50046`,
+   :cve_nist:`2024-50049`, :cve_nist:`2024-50059`, :cve_nist:`2024-50062`, :cve_nist:`2024-50074`,
+   :cve_nist:`2024-50082`, :cve_nist:`2024-50083`, :cve_nist:`2024-50093`, :cve_nist:`2024-50095`,
+   :cve_nist:`2024-50096`, :cve_nist:`2024-50099`, :cve_nist:`2024-50101`, :cve_nist:`2024-50103`,
+   :cve_nist:`2024-50110`, :cve_nist:`2024-50115`, :cve_nist:`2024-50116`, :cve_nist:`2024-50117`,
+   :cve_nist:`2024-50127`, :cve_nist:`2024-50128`, :cve_nist:`2024-50131`, :cve_nist:`2024-50134`,
+   :cve_nist:`2024-50141`, :cve_nist:`2024-50142`, :cve_nist:`2024-50143`, :cve_nist:`2024-50148`,
+   :cve_nist:`2024-50150`, :cve_nist:`2024-50151`, :cve_nist:`2024-50153`, :cve_nist:`2024-50154`,
+   :cve_nist:`2024-50156`, :cve_nist:`2024-50160`, :cve_nist:`2024-50162`, :cve_nist:`2024-50163`,
+   :cve_nist:`2024-50167`, :cve_nist:`2024-50168`, :cve_nist:`2024-50171`, :cve_nist:`2024-50179`,
+   :cve_nist:`2024-50180`, :cve_nist:`2024-50181`, :cve_nist:`2024-50182`, :cve_nist:`2024-50184`,
+   :cve_nist:`2024-50185`, :cve_nist:`2024-50186`, :cve_nist:`2024-50188`, :cve_nist:`2024-50189`,
+   :cve_nist:`2024-50191`, :cve_nist:`2024-50192`, :cve_nist:`2024-50193`, :cve_nist:`2024-50194`,
+   :cve_nist:`2024-50195`, :cve_nist:`2024-50196`, :cve_nist:`2024-50198`, :cve_nist:`2024-50201`,
+   :cve_nist:`2024-50202`, :cve_nist:`2024-50205`, :cve_nist:`2024-50208`, :cve_nist:`2024-50209`,
+   :cve_nist:`2024-50229`, :cve_nist:`2024-50230`, :cve_nist:`2024-50232`, :cve_nist:`2024-50233`,
+   :cve_nist:`2024-50234`, :cve_nist:`2024-50236`, :cve_nist:`2024-50237`, :cve_nist:`2024-50244`,
+   :cve_nist:`2024-50245`, :cve_nist:`2024-50247`, :cve_nist:`2024-50251`, :cve_nist:`2024-50257`,
+   :cve_nist:`2024-50259`, :cve_nist:`2024-50262`, :cve_nist:`2024-50264`, :cve_nist:`2024-50265`,
+   :cve_nist:`2024-50267`, :cve_nist:`2024-50268`, :cve_nist:`2024-50269`, :cve_nist:`2024-50273`,
+   :cve_nist:`2024-50278`, :cve_nist:`2024-50279`, :cve_nist:`2024-50282`, :cve_nist:`2024-50287`,
+   :cve_nist:`2024-50292`, :cve_nist:`2024-50296`, :cve_nist:`2024-50299`, :cve_nist:`2024-50301`,
+   :cve_nist:`2024-50302`, :cve_nist:`2024-53052`, :cve_nist:`2024-53055`, :cve_nist:`2024-53057`,
+   :cve_nist:`2024-53058`, :cve_nist:`2024-53059`, :cve_nist:`2024-53060`, :cve_nist:`2024-53061`,
+   :cve_nist:`2024-53063`, :cve_nist:`2024-53066`, :cve_nist:`2024-53088`, :cve_nist:`2024-53096`,
+   :cve_nist:`2024-53101`, :cve_nist:`2024-53103`, :cve_nist:`2024-53145`, :cve_nist:`2024-53146`,
+   :cve_nist:`2024-53150`, :cve_nist:`2024-53151`, :cve_nist:`2024-53155`, :cve_nist:`2024-53156`,
+   :cve_nist:`2024-53157`, :cve_nist:`2024-53165`, :cve_nist:`2024-53171`, :cve_nist:`2024-53173`,
+   :cve_nist:`2024-53226`, :cve_nist:`2024-53227`, :cve_nist:`2024-53237`, :cve_nist:`2024-56567`,
+   :cve_nist:`2024-56572`, :cve_nist:`2024-56574`, :cve_nist:`2024-56578`, :cve_nist:`2024-56581`,
+   :cve_nist:`2024-56593`, :cve_nist:`2024-56600`, :cve_nist:`2024-56601`, :cve_nist:`2024-56602`,
+   :cve_nist:`2024-56603`, :cve_nist:`2024-56605`, :cve_nist:`2024-56606`, :cve_nist:`2024-56614`,
+   :cve_nist:`2024-56622`, :cve_nist:`2024-56623`, :cve_nist:`2024-56629`, :cve_nist:`2024-56634`,
+   :cve_nist:`2024-56640`, :cve_nist:`2024-56642`, :cve_nist:`2024-56643`, :cve_nist:`2024-56648`,
+   :cve_nist:`2024-56650`, :cve_nist:`2024-56659`, :cve_nist:`2024-56662`, :cve_nist:`2024-56670`,
+   :cve_nist:`2024-56688`, :cve_nist:`2024-56694`, :cve_nist:`2024-56704`, :cve_nist:`2024-56708`,
+   :cve_nist:`2024-56720`, :cve_nist:`2024-56723`, :cve_nist:`2024-56724`, :cve_nist:`2024-56726`,
+   :cve_nist:`2024-56728`, :cve_nist:`2024-56739`, :cve_nist:`2024-56741`, :cve_nist:`2024-56745`,
+   :cve_nist:`2024-56746`, :cve_nist:`2024-56747`, :cve_nist:`2024-56748`, :cve_nist:`2024-56754`,
+   :cve_nist:`2024-56756`, :cve_nist:`2024-56770`, :cve_nist:`2024-56774`, :cve_nist:`2024-56776`,
+   :cve_nist:`2024-56777`, :cve_nist:`2024-56778`, :cve_nist:`2024-56779`, :cve_nist:`2024-56780`,
+   :cve_nist:`2024-56781`, :cve_nist:`2024-56785` and :cve_nist:`2024-56787`
+-  ovmf: Fix :cve_nist:`2022-36763`, :cve_nist:`2022-36764`, :cve_nist:`2022-36765`,
+   :cve_nist:`2023-45229`, :cve_nist:`2023-45230`, :cve_nist:`2023-45231`, :cve_nist:`2023-45232`,
+   :cve_nist:`2023-45233`, :cve_nist:`2023-45234`, :cve_nist:`2023-45235`, :cve_nist:`2023-45236`,
+   :cve_nist:`2023-45237`, :cve_nist:`2024-1298` and :cve_nist:`2024-38796`
+-  pixman: Ignore :cve_nist:`2023-37769`
+-  python3: Fix :cve_nist:`2024-9287`, :cve_nist:`2024-11168` and :cve_nist:`2024-50602`
+-  python3-pip: Fix :cve_nist:`2023-5752`
+-  python3-requests: Fix :cve_nist:`2024-35195`
+-  python3-zipp: Fix :cve_nist:`2024-5569`
+-  qemu: Fix :cve_nist:`2024-3446`, :cve_nist:`2024-3447` and :cve_nist:`2024-6505`
+-  qemu: Ignore :cve_nist:`2022-36648`
+-  subversion: Fix :cve_nist:`2024-46901`
+-  tiff: Fix :cve_nist:`2023-3164`
+-  tiff: Ignore :cve_nist:`2023-2731`
+-  webkitgtk: Fix :cve_nist:`2024-40776` and :cve_nist:`2024-40780`
+-  xserver-xorg: Fix :cve_nist:`2024-9632`
+-  xwayland: Fix :cve_nist:`2023-5380` and :cve_nist:`2024-0229`
+
+
+Fixes in Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~
+
+-  base-passwd: Add the sgx group
+-  base-passwd: Regenerate the patches
+-  base-passwd: Update the status for two patches
+-  base-passwd: Update to 3.5.52
+-  base-passwd: add the wheel group
+-  base-passwd: fix patchreview warning
+-  bitbake: fetch2: use persist_data context managers
+-  bitbake: fetch/wget: Increase timeout to 100s from 30s
+-  bitbake: persist_data: close connection in SQLTable __exit__
+-  build-appliance-image: Update to kirkstone head revision
+-  builder: set :term:`CVE_PRODUCT`
+-  contributor-guide: submit-changes.rst: suggest to remove the git signature
+-  cve-update-nvd2-native: Tweak to work better with NFS :term:`DL_DIR`
+-  dbus: disable assertions and enable only modular tests
+-  do_package/sstate/sstatesig: Change timestamp clamping to hash output only
+-  docs: Gather dependencies in poky.yaml.in
+-  docs: standards.md: add a section on admonitions
+-  gstreamer1.0: improve test reliability
+-  linux-yocto/5.10: update to v5.10.227
+-  linux-yocto/5.15: update to v5.15.175
+-  llvm: reduce size of -dbg package
+-  lttng-modules: fix build error after kernel update to 5.15.171
+-  migration-guides: add release notes for 4.0.23
+-  ninja: fix build with python 3.13
+-  oeqa/utils/gitarchive: Return tag name and improve exclude handling
+-  ovmf-native: remove .pyc files from install
+-  package.bbclass: Use shlex instead of deprecated pipes
+-  package_rpm: restrict rpm to 4 threads
+-  package_rpm: use zstd's default compression level
+-  poky.conf: add new tested distros
+-  poky.conf: bump version for 4.0.24
+-  poky.yaml.in: add missing locales dependency
+-  python3: upgrade to 3.10.16
+-  ref-manual: SSTATE_MIRRORS/SOURCE_MIRROR_URL: add instructions for mirror authentication
+-  ref-manual: classes: fix bin_package description
+-  ref-manual: devtool-reference: add warning note on deploy-target and shared objects
+-  ref-manual: move runtime-testing section to the test-manual
+-  ref-manual: packages: move ptest section to the test-manual
+-  ref-manual: system-requirements: update list of supported distros
+-  ref-manual: use standardized method accross both ubuntu and debian for locale install
+-  resulttool: Add --logfile-archive option to store mode
+-  resulttool: Allow store to filter to specific revisions
+-  resulttool: Clean up repoducible build logs
+-  resulttool: Fix passthrough of --all files in store mode
+-  resulttool: Handle ltp rawlogs as well as ptest
+-  resulttool: Improve repo layout for oeselftest results
+-  resulttool: Trim the precision of duration information
+-  resulttool: Use single space indentation in json output
+-  rootfs-postcommands.bbclass: make opkg status reproducible
+-  rxvt-unicode.inc: disable the terminfo installation by setting TIC to :
+-  sanity: check for working user namespaces
+-  scripts/install-buildtools: Update to 4.0.22
+-  selftest/reproducible: Clean up pathnames
+-  selftest/reproducible: Drop rawlogs
+-  test-manual: reproducible-builds.rst: document :term:`OEQA_REPRODUCIBLE_TEST_TARGET` and
+   :term:`OEQA_REPRODUCIBLE_TEST_SSTATE_TARGETS`
+-  test-manual: reproducible-builds.rst: show how to build a single package
+-  toolchain-shar-extract.sh: exit when post-relocate-setup.sh fails
+-  tzdata & tzcode-native: upgrade 2024b
+-  udev-extraconf: fix network.sh script did not configure hotplugged interfaces
+-  unzip: Fix configure tests to use modern C
+-  webkitgtk: Fix build on 32bit arm
+-  webkitgtk: fix perl-native dependency
+-  webkitgtk: reduce size of -dbg package
+-  wireless-regdb: upgrade to 2024.10.07
+
+
+Known Issues in Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+Contributors to Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+-  Aleksandar Nikolic
+-  Alex Kiernan
+-  Alexander Kanavin
+-  Alexandre Belloni
+-  Antonin Godard
+-  Archana Polampalli
+-  Bruce Ashfield
+-  Changqing Li
+-  Chen Qi
+-  Chris Laplante
+-  Divya Chellam
+-  Ernst Persson
+-  Guénaël Muller
+-  Hitendra Prajapati
+-  Hongxu Jia
+-  Jiaying Song
+-  Jinfeng Wang
+-  Khem Raj
+-  Lee Chee Yang
+-  Liyin Zhang
+-  Louis Rannou
+-  Markus Volk
+-  Mikko Rapeli
+-  Ovidiu Panait
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Regis Dargent
+-  Richard Purdie
+-  Rohini Sangam
+-  Ross Burton
+-  Soumya Sambu
+-  Steve Sakoman
+-  Trevor Gamblin
+-  Vijay Anusuri
+-  Wang Mingyu
+-  Yogita Urade
+-  Zahir Hussain
+
+
+Repositories / Downloads for Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.24 </poky/log/?h=yocto-4.0.24>`
+-  Git Revision: :yocto_git:`f50532593651dff82bc952288d786c55038c2c86 </poky/commit/?id=f50532593651dff82bc952288d786c55038c2c86>`
+-  Release Artefact: poky-f50532593651dff82bc952288d786c55038c2c86
+-  sha: 0aa062d19510394748db9a2d6ded2d764f435383296d9c94fb6b25755280556e
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.24/poky-f50532593651dff82bc952288d786c55038c2c86.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/poky-f50532593651dff82bc952288d786c55038c2c86.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.24 </openembedded-core/log/?h=yocto-4.0.24>`
+-  Git Revision: :oe_git:`a270d4c957259761bcc7382fcc54642a02f9fc7d </openembedded-core/commit/?id=a270d4c957259761bcc7382fcc54642a02f9fc7d>`
+-  Release Artefact: oecore-a270d4c957259761bcc7382fcc54642a02f9fc7d
+-  sha: b08b9b16c8ffa587d521ad28e24e38c79d757a6f0839d18165ebac3081a34b68
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.24/oecore-a270d4c957259761bcc7382fcc54642a02f9fc7d.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/oecore-a270d4c957259761bcc7382fcc54642a02f9fc7d.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.24 </meta-mingw/log/?h=yocto-4.0.24>`
+-  Git Revision: :yocto_git:`87c22abb1f11be430caf4372e6b833dc7d77564e </meta-mingw/commit/?id=87c22abb1f11be430caf4372e6b833dc7d77564e>`
+-  Release Artefact: meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e
+-  sha: f0bc4873e2e0319fb9d6d6ab9b98eb3f89664d4339a167d2db6a787dd12bc1a8
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.24/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.24 </meta-gplv2/log/?h=yocto-4.0.24>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.24/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.24 </bitbake/log/?h=yocto-4.0.24>`
+-  Git Revision: :oe_git:`3f88b005244a0afb5d5c7260e54a94a453ec9b3e </bitbake/commit/?id=3f88b005244a0afb5d5c7260e54a94a453ec9b3e>`
+-  Release Artefact: bitbake-3f88b005244a0afb5d5c7260e54a94a453ec9b3e
+-  sha: 31f442b72ec7d81ca75509b1a7179c3fe3942528b1e31c823b21a413244bd15b
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.24/bitbake-3f88b005244a0afb5d5c7260e54a94a453ec9b3e.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/bitbake-3f88b005244a0afb5d5c7260e54a94a453ec9b3e.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.24 </yocto-docs/log/?h=yocto-4.0.24>`
+-  Git Revision: :yocto_git:`3128bf149f40928e6c2a3e264590a0c6c9778c6a </yocto-docs/commit/?id=3128bf149f40928e6c2a3e264590a0c6c9778c6a>`
+

documentation/migration-guides/release-notes-4.0.25.rst

@@ -0,0 +1,167 @@
+Release notes for Yocto-4.0.25 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.25
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  avahi: Fix :cve_nist:`2024-52616`
+-  binutils: Fix :cve_nist:`2024-53589`
+-  gdb: Fix :cve_nist:`2024-53589`
+-  go: Fix :cve_nist:`2024-34155`, :cve_nist:`2024-34156`, :cve_nist:`2024-34158` and
+   :cve_nist:`2024-45336`
+-  gstreamer1.0: Ignore :cve_nist:`2024-47537`, :cve_nist:`2024-47539`, :cve_nist:`2024-47540`,
+   :cve_nist:`2024-47543`, :cve_nist:`2024-47544`, :cve_nist:`2024-47545`, :cve_nist:`2024-47538`,
+   :cve_nist:`2024-47541`, :cve_nist:`2024-47542`, :cve_nist:`2024-47600`, :cve_nist:`2024-47607`,
+   :cve_nist:`2024-47615`, :cve_nist:`2024-47835`, :cve_nist:`2024-47546`, :cve_nist:`2024-47596`,
+   :cve_nist:`2024-47597`, :cve_nist:`2024-47598`, :cve_nist:`2024-47599`, :cve_nist:`2024-47601`,
+   :cve_nist:`2024-47777`, :cve_nist:`2024-47778`, :cve_nist:`2024-47834`, :cve_nist:`2024-47602`,
+   :cve_nist:`2024-47603`, :cve_nist:`2024-47613`, :cve_nist:`2024-47774`, :cve_nist:`2024-47775`
+   and :cve_nist:`2024-47776`
+-  linux-yocto/5.15: Fix :cve_nist:`2024-36476`, :cve_nist:`2024-55916`, :cve_nist:`2024-56369`,
+   :cve_nist:`2024-56626`, :cve_nist:`2024-56627`, :cve_nist:`2024-56715`, :cve_nist:`2024-56716`,
+   :cve_nist:`2024-57802`, :cve_nist:`2024-57807`, :cve_nist:`2024-57841`, :cve_nist:`2024-57890`,
+   :cve_nist:`2024-57896`, :cve_nist:`2024-57900`, :cve_nist:`2024-57910`, :cve_nist:`2024-57911`,
+   :cve_nist:`2024-57938`, :cve_nist:`2024-57951`, :cve_nist:`2025-21631`, :cve_nist:`2025-21665`,
+   :cve_nist:`2025-21666`, :cve_nist:`2025-21669`, :cve_nist:`2025-21680`, :cve_nist:`2025-21683`,
+   :cve_nist:`2025-21694`, :cve_nist:`2025-21697` and :cve_nist:`2025-21699`
+-  ofono: Fix :cve_nist:`2024-7539`, :cve_nist:`2024-7540`, :cve_nist:`2024-7541`,
+   :cve_nist:`2024-7542`, :cve_nist:`2024-7543`, :cve_nist:`2024-7544`, :cve_nist:`2024-7545`,
+   :cve_nist:`2024-7546` and :cve_nist:`2024-7547`
+-  openssl: Fix :cve_nist:`2024-13176`
+-  rsync: Fix :cve_nist:`2024-12084`, :cve_nist:`2024-12085`, :cve_nist:`2024-12086`,
+   :cve_nist:`2024-12087`, :cve_nist:`2024-12088` and :cve_nist:`2024-12747`
+-  ruby: Fix :cve_nist:`2024-49761`
+-  socat: Fix :cve_nist:`2024-54661`
+-  vte: Fix :cve_nist:`2024-37535`
+-  wget: Fix :cve_nist:`2024-10524`
+
+
+Fixes in Yocto-4.0.25
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bitbake: tests/fetch: Fix git shallow test failure with git >= 2.48
+-  build-appliance-image: Update to kirkstone head revision
+-  classes-global/insane: Look up all runtime providers for file-rdeps
+-  classes/nativesdk: also override :term:`TUNE_PKGARCH`
+-  classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture
+-  cmake: apply parallel build settings to ptest tasks
+-  dev-manual/building: document the initramfs-framework recipe
+-  docs: Update autobuilder URLs to valkyrie
+-  documentation: Fix typo in standards.md
+-  glibc: Suppress GCC -Os warning on user2netname for sunrpc
+-  glibc: stable 2.35 branch updates
+-  lib/packagedata.py: Add API to iterate over rprovides
+-  linux-yocto/5.15: upgrade to v5.15.178
+-  migration-guides: add release notes for 4.0.24
+-  openssl: upgrade to 3.0.16
+-  poky.conf: bump version for 4.0.25
+-  python3: Treat UID/GID overflow as failure
+-  rsync: Delete pedantic errors re-ordering patch
+-  rsync: upgrade to 3.2.7
+-  rust-common.bbclass: soft assignment for RUSTLIB path
+-  scripts/install-buildtools: Update to 4.0.23
+-  test-manual/reproducible-builds: fix reproducible links
+
+
+Known Issues in Yocto-4.0.25
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.25
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aleksandar Nikolic
+-  Alexander Kanavin
+-  Antonin Godard
+-  Archana Polampalli
+-  Bruce Ashfield
+-  Deepesh Varatharajan
+-  Divya Chellam
+-  Joshua Watt
+-  Khem Raj
+-  Lee Chee Yang
+-  Nikhil R
+-  Pedro Ferreira
+-  Peter Marko
+-  Praveen Kumar
+-  Richard Purdie
+-  Ross Burton
+-  Simon A. Eugster
+-  Steve Sakoman
+-  Yash Shinde
+-  Yogita Urade
+-  Zhang Peng
+
+
+Repositories / Downloads for Yocto-4.0.25
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.25 </poky/log/?h=yocto-4.0.25>`
+-  Git Revision: :yocto_git:`b5aa03f336c121269551f9e7baed4c677c76bb39 </poky/commit/?id=b5aa03f336c121269551f9e7baed4c677c76bb39>`
+-  Release Artefact: poky-b5aa03f336c121269551f9e7baed4c677c76bb39
+-  sha: 7afbcb25f0dd89a4fb6dd4c5945061705ef9ce79a6863806278603273c2b3b4a
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.25/poky-b5aa03f336c121269551f9e7baed4c677c76bb39.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.25/poky-b5aa03f336c121269551f9e7baed4c677c76bb39.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.25 </openembedded-core/log/?h=yocto-4.0.25>`
+-  Git Revision: :oe_git:`5a794fd244f7fdeb426bd5e3def6b4effc0e8c62 </openembedded-core/commit/?id=5a794fd244f7fdeb426bd5e3def6b4effc0e8c62>`
+-  Release Artefact: oecore-5a794fd244f7fdeb426bd5e3def6b4effc0e8c62
+-  sha: 8fc93109693e5f4702b3fe0633b6be833605291b3d595dc8bdeb6379f40cd2de
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.25/oecore-5a794fd244f7fdeb426bd5e3def6b4effc0e8c62.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.25/oecore-5a794fd244f7fdeb426bd5e3def6b4effc0e8c62.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.25 </meta-mingw/log/?h=yocto-4.0.25>`
+-  Git Revision: :yocto_git:`87c22abb1f11be430caf4372e6b833dc7d77564e </meta-mingw/commit/?id=87c22abb1f11be430caf4372e6b833dc7d77564e>`
+-  Release Artefact: meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e
+-  sha: f0bc4873e2e0319fb9d6d6ab9b98eb3f89664d4339a167d2db6a787dd12bc1a8
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.25/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.25/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.25 </meta-gplv2/log/?h=yocto-4.0.25>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.25/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.25/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.25 </bitbake/log/?h=yocto-4.0.25>`
+-  Git Revision: :oe_git:`e71f1ce53cf3b8320caa481ae62d1ce2900c4670 </bitbake/commit/?id=e71f1ce53cf3b8320caa481ae62d1ce2900c4670>`
+-  Release Artefact: bitbake-e71f1ce53cf3b8320caa481ae62d1ce2900c4670
+-  sha: 007eef35174586c85b233f4ec91578956fe21e0236f7ca2c3f90f9d034f94b5b
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.25/bitbake-e71f1ce53cf3b8320caa481ae62d1ce2900c4670.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.25/bitbake-e71f1ce53cf3b8320caa481ae62d1ce2900c4670.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.25 </yocto-docs/log/?h=yocto-4.0.25>`
+-  Git Revision: :yocto_git:`c6dce0c77481dee7b0a0fcdc803f755ceccef234 </yocto-docs/commit/?id=c6dce0c77481dee7b0a0fcdc803f755ceccef234>`
+

documentation/migration-guides/release-notes-5.0.7.rst

@@ -0,0 +1,331 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-5.0.7 (Scarthgap)
+-----------------------------------------
+
+Security Fixes in Yocto-5.0.7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  avahi: Fix :cve_nist:`2024-52616`
+-  binutils: Fix :cve_nist:`2024-53589`
+-  ffmpeg: Fix :cve_nist:`2024-35366`, :cve_nist:`2024-35367` and :cve_nist:`2024-35368`
+-  gstreamer1.0-plugins-base: Fix :cve_nist:`2024-47538`, :cve_nist:`2024-47541`,
+   :cve_nist:`2024-47542`, :cve_nist:`2024-47600`, :cve_nist:`2024-47607`, :cve_nist:`2024-47615`
+   and :cve_nist:`2024-47835`
+-  gstreamer1.0-plugins-good: Fix :cve_nist:`2024-47537`, :cve_nist:`2024-47539`,
+   :cve_nist:`2024-47540`, :cve_nist:`2024-47543`, :cve_nist:`2024-47544`, :cve_nist:`2024-47545`,
+   :cve_nist:`2024-47546`, :cve_nist:`2024-47596`, :cve_nist:`2024-47597`, :cve_nist:`2024-47598`,
+   :cve_nist:`2024-47599`, :cve_nist:`2024-47601`, :cve_nist:`2024-47602`, :cve_nist:`2024-47603`,
+   :cve_nist:`2024-47606`, :cve_nist:`2024-47613`, :cve_nist:`2024-47774`, :cve_nist:`2024-47775`,
+   :cve_nist:`2024-47776`, :cve_nist:`2024-47777`, :cve_nist:`2024-47778` and :cve_nist:`2024-47834`
+-  gstreamer1.0: Ignore :cve_nist:`2024-47537`, :cve_nist:`2024-47539`, :cve_nist:`2024-47540`,
+   :cve_nist:`2024-47543`, :cve_nist:`2024-47544`, :cve_nist:`2024-47545`, :cve_nist:`2024-47538`,
+   :cve_nist:`2024-47541`, :cve_nist:`2024-47542`, :cve_nist:`2024-47600`, :cve_nist:`2024-47607`,
+   :cve_nist:`2024-47615`, :cve_nist:`2024-47835`, :cve_nist:`2024-47546`, :cve_nist:`2024-47596`,
+   :cve_nist:`2024-47597`, :cve_nist:`2024-47598`, :cve_nist:`2024-47599`, :cve_nist:`2024-47601`,
+   :cve_nist:`2024-47602`, :cve_nist:`2024-47603`, :cve_nist:`2024-47613`, :cve_nist:`2024-47774`,
+   :cve_nist:`2024-47775`, :cve_nist:`2024-47776`, :cve_nist:`2024-47777`, :cve_nist:`2024-47778`
+   and :cve_nist:`2024-47834`
+-  libarchive: Fix :cve_nist:`2024-20696`
+-  libxml2: Fix :cve_nist:`2024-40896`
+-  linux-yocto/6.6: Fix :cve_nist:`2024-27059`, :cve_nist:`2024-43098`, :cve_nist:`2024-45828`,
+   :cve_nist:`2024-47141`, :cve_nist:`2024-47143`, :cve_nist:`2024-47704`, :cve_nist:`2024-47809`,
+   :cve_nist:`2024-48873`, :cve_nist:`2024-48875`, :cve_nist:`2024-48881`, :cve_nist:`2024-49863`,
+   :cve_nist:`2024-49864`, :cve_nist:`2024-49866`, :cve_nist:`2024-49867`, :cve_nist:`2024-49868`,
+   :cve_nist:`2024-49870`, :cve_nist:`2024-49871`, :cve_nist:`2024-49874`, :cve_nist:`2024-49875`,
+   :cve_nist:`2024-49877`, :cve_nist:`2024-49878`, :cve_nist:`2024-49879`, :cve_nist:`2024-49881`,
+   :cve_nist:`2024-49882`, :cve_nist:`2024-49883`, :cve_nist:`2024-49884`, :cve_nist:`2024-49886`,
+   :cve_nist:`2024-49889`, :cve_nist:`2024-49890`, :cve_nist:`2024-49892`, :cve_nist:`2024-49894`,
+   :cve_nist:`2024-49895`, :cve_nist:`2024-49896`, :cve_nist:`2024-49900`, :cve_nist:`2024-49901`,
+   :cve_nist:`2024-49902`, :cve_nist:`2024-49903`, :cve_nist:`2024-49905`, :cve_nist:`2024-49907`,
+   :cve_nist:`2024-49912`, :cve_nist:`2024-49913`, :cve_nist:`2024-49924`, :cve_nist:`2024-49925`,
+   :cve_nist:`2024-49927`, :cve_nist:`2024-49929`, :cve_nist:`2024-49930`, :cve_nist:`2024-49931`,
+   :cve_nist:`2024-49933`, :cve_nist:`2024-49935`, :cve_nist:`2024-49936`, :cve_nist:`2024-49937`,
+   :cve_nist:`2024-49938`, :cve_nist:`2024-49939`, :cve_nist:`2024-49944`, :cve_nist:`2024-49946`,
+   :cve_nist:`2024-49947`, :cve_nist:`2024-49948`, :cve_nist:`2024-49949`, :cve_nist:`2024-49950`,
+   :cve_nist:`2024-49951`, :cve_nist:`2024-49952`, :cve_nist:`2024-49953`, :cve_nist:`2024-49954`,
+   :cve_nist:`2024-49955`, :cve_nist:`2024-49957`, :cve_nist:`2024-49958`, :cve_nist:`2024-49959`,
+   :cve_nist:`2024-49960`, :cve_nist:`2024-49961`, :cve_nist:`2024-49962`, :cve_nist:`2024-49963`,
+   :cve_nist:`2024-49965`, :cve_nist:`2024-49966`, :cve_nist:`2024-49969`, :cve_nist:`2024-49973`,
+   :cve_nist:`2024-49975`, :cve_nist:`2024-49976`, :cve_nist:`2024-49977`, :cve_nist:`2024-49978`,
+   :cve_nist:`2024-49980`, :cve_nist:`2024-49981`, :cve_nist:`2024-49982`, :cve_nist:`2024-49983`,
+   :cve_nist:`2024-49985`, :cve_nist:`2024-49986`, :cve_nist:`2024-49987`, :cve_nist:`2024-49988`,
+   :cve_nist:`2024-49989`, :cve_nist:`2024-49991`, :cve_nist:`2024-49992`, :cve_nist:`2024-49995`,
+   :cve_nist:`2024-49996`, :cve_nist:`2024-49997`, :cve_nist:`2024-50000`, :cve_nist:`2024-50001`,
+   :cve_nist:`2024-50002`, :cve_nist:`2024-50003`, :cve_nist:`2024-50005`, :cve_nist:`2024-50006`,
+   :cve_nist:`2024-50007`, :cve_nist:`2024-50008`, :cve_nist:`2024-50012`, :cve_nist:`2024-50013`,
+   :cve_nist:`2024-50015`, :cve_nist:`2024-50016`, :cve_nist:`2024-50019`, :cve_nist:`2024-50022`,
+   :cve_nist:`2024-50023`, :cve_nist:`2024-50024`, :cve_nist:`2024-50026`, :cve_nist:`2024-50029`,
+   :cve_nist:`2024-50031`, :cve_nist:`2024-50032`, :cve_nist:`2024-50033`, :cve_nist:`2024-50035`,
+   :cve_nist:`2024-50036`, :cve_nist:`2024-50038`, :cve_nist:`2024-50039`, :cve_nist:`2024-50040`,
+   :cve_nist:`2024-50041`, :cve_nist:`2024-50044`, :cve_nist:`2024-50045`, :cve_nist:`2024-50046`,
+   :cve_nist:`2024-50047`, :cve_nist:`2024-50048`, :cve_nist:`2024-50049`, :cve_nist:`2024-50051`,
+   :cve_nist:`2024-50055`, :cve_nist:`2024-50057`, :cve_nist:`2024-50058`, :cve_nist:`2024-50059`,
+   :cve_nist:`2024-50060`, :cve_nist:`2024-50061`, :cve_nist:`2024-50062`, :cve_nist:`2024-50063`,
+   :cve_nist:`2024-50064`, :cve_nist:`2024-50065`, :cve_nist:`2024-50066`, :cve_nist:`2024-50069`,
+   :cve_nist:`2024-50070`, :cve_nist:`2024-50072`, :cve_nist:`2024-50073`, :cve_nist:`2024-50074`,
+   :cve_nist:`2024-50075`, :cve_nist:`2024-50076`, :cve_nist:`2024-50077`, :cve_nist:`2024-50078`,
+   :cve_nist:`2024-50080`, :cve_nist:`2024-50082`, :cve_nist:`2024-50083`, :cve_nist:`2024-50084`,
+   :cve_nist:`2024-50085`, :cve_nist:`2024-50086`, :cve_nist:`2024-50087`, :cve_nist:`2024-50088`,
+   :cve_nist:`2024-50093`, :cve_nist:`2024-50095`, :cve_nist:`2024-50096`, :cve_nist:`2024-50098`,
+   :cve_nist:`2024-50099`, :cve_nist:`2024-50101`, :cve_nist:`2024-50103`, :cve_nist:`2024-50108`,
+   :cve_nist:`2024-50110`, :cve_nist:`2024-50111`, :cve_nist:`2024-50112`, :cve_nist:`2024-50115`,
+   :cve_nist:`2024-50116`, :cve_nist:`2024-50117`, :cve_nist:`2024-50120`, :cve_nist:`2024-50121`,
+   :cve_nist:`2024-50124`, :cve_nist:`2024-50125`, :cve_nist:`2024-50126`, :cve_nist:`2024-50127`,
+   :cve_nist:`2024-50128`, :cve_nist:`2024-50130`, :cve_nist:`2024-50131`, :cve_nist:`2024-50133`,
+   :cve_nist:`2024-50134`, :cve_nist:`2024-50135`, :cve_nist:`2024-50136`, :cve_nist:`2024-50139`,
+   :cve_nist:`2024-50140`, :cve_nist:`2024-50141`, :cve_nist:`2024-50142`, :cve_nist:`2024-50143`,
+   :cve_nist:`2024-50145`, :cve_nist:`2024-50147`, :cve_nist:`2024-50148`, :cve_nist:`2024-50150`,
+   :cve_nist:`2024-50151`, :cve_nist:`2024-50152`, :cve_nist:`2024-50153`, :cve_nist:`2024-50154`,
+   :cve_nist:`2024-50155`, :cve_nist:`2024-50156`, :cve_nist:`2024-50158`, :cve_nist:`2024-50159`,
+   :cve_nist:`2024-50160`, :cve_nist:`2024-50162`, :cve_nist:`2024-50163`, :cve_nist:`2024-50164`,
+   :cve_nist:`2024-50166`, :cve_nist:`2024-50167`, :cve_nist:`2024-50168`, :cve_nist:`2024-50169`,
+   :cve_nist:`2024-50170`, :cve_nist:`2024-50171`, :cve_nist:`2024-50172`, :cve_nist:`2024-50175`,
+   :cve_nist:`2024-50176`, :cve_nist:`2024-50179`, :cve_nist:`2024-50180`, :cve_nist:`2024-50181`,
+   :cve_nist:`2024-50182`, :cve_nist:`2024-50183`, :cve_nist:`2024-50184`, :cve_nist:`2024-50185`,
+   :cve_nist:`2024-50186`, :cve_nist:`2024-50187`, :cve_nist:`2024-50188`, :cve_nist:`2024-50189`,
+   :cve_nist:`2024-50191`, :cve_nist:`2024-50192`, :cve_nist:`2024-50193`, :cve_nist:`2024-50194`,
+   :cve_nist:`2024-50195`, :cve_nist:`2024-50196`, :cve_nist:`2024-50198`, :cve_nist:`2024-50201`,
+   :cve_nist:`2024-50202`, :cve_nist:`2024-50205`, :cve_nist:`2024-50208`, :cve_nist:`2024-50209`,
+   :cve_nist:`2024-50211`, :cve_nist:`2024-50215`, :cve_nist:`2024-50222`, :cve_nist:`2024-50223`,
+   :cve_nist:`2024-50224`, :cve_nist:`2024-50226`, :cve_nist:`2024-50229`, :cve_nist:`2024-50230`,
+   :cve_nist:`2024-50231`, :cve_nist:`2024-50232`, :cve_nist:`2024-50233`, :cve_nist:`2024-50234`,
+   :cve_nist:`2024-50235`, :cve_nist:`2024-50236`, :cve_nist:`2024-50237`, :cve_nist:`2024-50239`,
+   :cve_nist:`2024-50240`, :cve_nist:`2024-50242`, :cve_nist:`2024-50243`, :cve_nist:`2024-50244`,
+   :cve_nist:`2024-50245`, :cve_nist:`2024-50246`, :cve_nist:`2024-50247`, :cve_nist:`2024-50248`,
+   :cve_nist:`2024-50249`, :cve_nist:`2024-50250`, :cve_nist:`2024-50251`, :cve_nist:`2024-50252`,
+   :cve_nist:`2024-50255`, :cve_nist:`2024-50256`, :cve_nist:`2024-50257`, :cve_nist:`2024-50258`,
+   :cve_nist:`2024-50259`, :cve_nist:`2024-50261`, :cve_nist:`2024-50262`, :cve_nist:`2024-50264`,
+   :cve_nist:`2024-50265`, :cve_nist:`2024-50267`, :cve_nist:`2024-50268`, :cve_nist:`2024-50269`,
+   :cve_nist:`2024-50271`, :cve_nist:`2024-50272`, :cve_nist:`2024-50273`, :cve_nist:`2024-50275`,
+   :cve_nist:`2024-50276`, :cve_nist:`2024-50278`, :cve_nist:`2024-50279`, :cve_nist:`2024-50282`,
+   :cve_nist:`2024-50283`, :cve_nist:`2024-50284`, :cve_nist:`2024-50285`, :cve_nist:`2024-50286`,
+   :cve_nist:`2024-50287`, :cve_nist:`2024-50292`, :cve_nist:`2024-50296`, :cve_nist:`2024-50298`,
+   :cve_nist:`2024-50299`, :cve_nist:`2024-50300`, :cve_nist:`2024-50301`, :cve_nist:`2024-50302`,
+   :cve_nist:`2024-53042`, :cve_nist:`2024-53043`, :cve_nist:`2024-53046`, :cve_nist:`2024-53047`,
+   :cve_nist:`2024-53052`, :cve_nist:`2024-53055`, :cve_nist:`2024-53057`, :cve_nist:`2024-53058`,
+   :cve_nist:`2024-53059`, :cve_nist:`2024-53060`, :cve_nist:`2024-53061`, :cve_nist:`2024-53063`,
+   :cve_nist:`2024-53066`, :cve_nist:`2024-53068`, :cve_nist:`2024-53072`, :cve_nist:`2024-53076`,
+   :cve_nist:`2024-53079`, :cve_nist:`2024-53081`, :cve_nist:`2024-53082`, :cve_nist:`2024-53083`,
+   :cve_nist:`2024-53088`, :cve_nist:`2024-53091`, :cve_nist:`2024-53093`, :cve_nist:`2024-53094`,
+   :cve_nist:`2024-53096`, :cve_nist:`2024-53099`, :cve_nist:`2024-53100`, :cve_nist:`2024-53101`,
+   :cve_nist:`2024-53103`, :cve_nist:`2024-53108`, :cve_nist:`2024-53109`, :cve_nist:`2024-53110`,
+   :cve_nist:`2024-53112`, :cve_nist:`2024-53113`, :cve_nist:`2024-53119`, :cve_nist:`2024-53120`,
+   :cve_nist:`2024-53121`, :cve_nist:`2024-53122`, :cve_nist:`2024-53123`, :cve_nist:`2024-53126`,
+   :cve_nist:`2024-53127`, :cve_nist:`2024-53129`, :cve_nist:`2024-53130`, :cve_nist:`2024-53131`,
+   :cve_nist:`2024-53134`, :cve_nist:`2024-53135`, :cve_nist:`2024-53138`, :cve_nist:`2024-53139`,
+   :cve_nist:`2024-53140`, :cve_nist:`2024-53141`, :cve_nist:`2024-53142`, :cve_nist:`2024-53145`,
+   :cve_nist:`2024-53146`, :cve_nist:`2024-53150`, :cve_nist:`2024-53151`, :cve_nist:`2024-53154`,
+   :cve_nist:`2024-53155`, :cve_nist:`2024-53156`, :cve_nist:`2024-53157`, :cve_nist:`2024-53161`,
+   :cve_nist:`2024-53165`, :cve_nist:`2024-53166`, :cve_nist:`2024-53168`, :cve_nist:`2024-53171`,
+   :cve_nist:`2024-53173`, :cve_nist:`2024-53175`, :cve_nist:`2024-53180`, :cve_nist:`2024-53188`,
+   :cve_nist:`2024-53191`, :cve_nist:`2024-53200`, :cve_nist:`2024-53202`, :cve_nist:`2024-53208`,
+   :cve_nist:`2024-53210`, :cve_nist:`2024-53213`, :cve_nist:`2024-53215`, :cve_nist:`2024-53217`,
+   :cve_nist:`2024-53224`, :cve_nist:`2024-53226`, :cve_nist:`2024-53227`, :cve_nist:`2024-53230`,
+   :cve_nist:`2024-53231`, :cve_nist:`2024-53237`, :cve_nist:`2024-53239`, :cve_nist:`2024-54683`,
+   :cve_nist:`2024-55916`, :cve_nist:`2024-56369`, :cve_nist:`2024-56538`, :cve_nist:`2024-56551`,
+   :cve_nist:`2024-56567`, :cve_nist:`2024-56568`, :cve_nist:`2024-56569`, :cve_nist:`2024-56572`,
+   :cve_nist:`2024-56574`, :cve_nist:`2024-56575`, :cve_nist:`2024-56577`, :cve_nist:`2024-56578`,
+   :cve_nist:`2024-56579`, :cve_nist:`2024-56581`, :cve_nist:`2024-56587`, :cve_nist:`2024-56593`,
+   :cve_nist:`2024-56595`, :cve_nist:`2024-56596`, :cve_nist:`2024-56598`, :cve_nist:`2024-56600`,
+   :cve_nist:`2024-56601`, :cve_nist:`2024-56602`, :cve_nist:`2024-56603`, :cve_nist:`2024-56604`,
+   :cve_nist:`2024-56605`, :cve_nist:`2024-56606`, :cve_nist:`2024-56611`, :cve_nist:`2024-56613`,
+   :cve_nist:`2024-56614`, :cve_nist:`2024-56615`, :cve_nist:`2024-56617`, :cve_nist:`2024-56622`,
+   :cve_nist:`2024-56623`, :cve_nist:`2024-56626`, :cve_nist:`2024-56627`, :cve_nist:`2024-56629`,
+   :cve_nist:`2024-56631`, :cve_nist:`2024-56634`, :cve_nist:`2024-56635`, :cve_nist:`2024-56640`,
+   :cve_nist:`2024-56642`, :cve_nist:`2024-56643`, :cve_nist:`2024-56648`, :cve_nist:`2024-56649`,
+   :cve_nist:`2024-56650`, :cve_nist:`2024-56651`, :cve_nist:`2024-56653`, :cve_nist:`2024-56654`,
+   :cve_nist:`2024-56657`, :cve_nist:`2024-56658`, :cve_nist:`2024-56659`, :cve_nist:`2024-56660`,
+   :cve_nist:`2024-56662`, :cve_nist:`2024-56663`, :cve_nist:`2024-56664`, :cve_nist:`2024-56667`,
+   :cve_nist:`2024-56670`, :cve_nist:`2024-56672`, :cve_nist:`2024-56675`, :cve_nist:`2024-56687`,
+   :cve_nist:`2024-56688`, :cve_nist:`2024-56689`, :cve_nist:`2024-56692`, :cve_nist:`2024-56694`,
+   :cve_nist:`2024-56698`, :cve_nist:`2024-56704`, :cve_nist:`2024-56708`, :cve_nist:`2024-56710`,
+   :cve_nist:`2024-56715`, :cve_nist:`2024-56716`, :cve_nist:`2024-56717`, :cve_nist:`2024-56718`,
+   :cve_nist:`2024-56720`, :cve_nist:`2024-56722`, :cve_nist:`2024-56723`, :cve_nist:`2024-56724`,
+   :cve_nist:`2024-56725`, :cve_nist:`2024-56726`, :cve_nist:`2024-56727`, :cve_nist:`2024-56728`,
+   :cve_nist:`2024-56729`, :cve_nist:`2024-56739`, :cve_nist:`2024-56741`, :cve_nist:`2024-56744`,
+   :cve_nist:`2024-56745`, :cve_nist:`2024-56746`, :cve_nist:`2024-56747`, :cve_nist:`2024-56748`,
+   :cve_nist:`2024-56751`, :cve_nist:`2024-56752`, :cve_nist:`2024-56754`, :cve_nist:`2024-56755`,
+   :cve_nist:`2024-56756`, :cve_nist:`2024-56760`, :cve_nist:`2024-56763`, :cve_nist:`2024-56765`,
+   :cve_nist:`2024-56767`, :cve_nist:`2024-56769`, :cve_nist:`2024-56770`, :cve_nist:`2024-56774`,
+   :cve_nist:`2024-56776`, :cve_nist:`2024-56777`, :cve_nist:`2024-56778`, :cve_nist:`2024-56779`,
+   :cve_nist:`2024-56780`, :cve_nist:`2024-56781`, :cve_nist:`2024-56783`, :cve_nist:`2024-56785`,
+   :cve_nist:`2024-56786`, :cve_nist:`2024-56787`, :cve_nist:`2024-57798`, :cve_nist:`2024-57807`
+   and :cve_nist:`2024-57874`
+-  ofono: Fix :cve_nist:`2023-4232`, :cve_nist:`2023-4235`, :cve_nist:`2024-7539`,
+   :cve_nist:`2024-7540`, :cve_nist:`2024-7541`, :cve_nist:`2024-7542`, :cve_nist:`2024-7543`,
+   :cve_nist:`2024-7544`, :cve_nist:`2024-7545`, :cve_nist:`2024-7546` and :cve_nist:`2024-7547`
+-  rsync: Fix :cve_nist:`2024-12084`, :cve_nist:`2024-12085`, :cve_nist:`2024-12086`,
+   :cve_nist:`2024-12087`, :cve_nist:`2024-12088` and :cve_nist:`2024-12747`
+-  socat: Fix :cve_nist:`2024-54661`
+-  subversion: Fix :cve_nist:`2024-46901`
+-  wget: Fix :cve_nist:`2024-10524`
+
+
+Fixes in Yocto-5.0.7
+~~~~~~~~~~~~~~~~~~~~
+
+-  bitbake: cooker: Make cooker 'skiplist' per-multiconfig/mc
+-  bitbake: tests/fetch: Fix git shallow test failure with git >= 2.48
+-  bitbake: ui/knotty: print log paths for failed tasks in summary
+-  bitbake: ui/knotty: respect NO_COLOR & check for tty; rename print_hyperlink => format_hyperlink
+-  bluez5: Revert "bluez5: remove configuration files from install task"
+-  bluez5: backport patch to fix address type when loading keys
+-  boost: fix do_fetch error
+-  build-appliance-image: Update to scarthgap head revision
+-  classes/nativesdk: also override :term:`TUNE_PKGARCH`
+-  classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture
+-  contributor-guide/submit-changes.rst: suggest to remove the git signature
+-  cve-update-nvd2-native: Handle :term:`BB_NO_NETWORK` and missing db
+-  cve-update-nvd2-native: Tweak to work better with NFS :term:`DL_DIR`
+-  dev-manual/bmaptool.rst: correct command for bmaptool-native
+-  dev-manual/bmaptool.rst: simplify and fix instructions
+-  dev-manual: fix styling of references to bmaptool
+-  docs: Gather dependencies in poky.yaml.in
+-  docs: Update autobuilder URLs to valkyrie
+-  docs: Update the documentation for :term:`SRCPV`
+-  gcc: Fix c++: tweak for Wrange-loop-construct
+-  groff: Fix race issues for parallel build
+-  libgfortran: fix buildpath QA issue
+-  libxml2: Upgrade to 2.12.9
+-  linux-yocto/6.6: bsp/genericarm64: disable ARM64_SME
+-  linux-yocto/6.6: genericarm64.cfg: enable CONFIG_DMA_CMA
+-  linux-yocto/6.6: update to v6.6.69
+-  lttng-modules: fix sched_stat_runtime changed in Linux 6.6.66
+-  migration-guides: add release notes for 5.0.6
+-  oeqa/ssh: allow to retrieve raw, unformatted ouput
+-  ovmf-native: remove .pyc files from install
+-  poky.conf: add new tested distros
+-  poky.conf: bump version for 5.0.7
+-  poky.yaml.in: add missing locales dependency
+-  poky.yaml.in: replace inkscape dependency by librsvg2-bin
+-  populate_sdk_ext: write_local_conf add shutil import
+-  pulseaudio: fix webrtc audio depdency
+-  python3-requests: upgrade to 2.32.3
+-  python3: Drop empty patch
+-  python3: add dependency on -compression to -core
+-  python3: upgrade to 3.12.7
+-  ref-manual: move runtime-testing section to the test-manual
+-  ref-manual: use standardized method accross both ubuntu and debian for locale install
+-  ref-manual: SSTATE_MIRRORS/SOURCE_MIRROR_URL: add instructions for mirror authentication
+-  reproducible-builds.rst: show how to build a single package
+-  rust-target-config: Fix TARGET_C_INT_WIDTH with correct size
+-  rust: Revert "rust: Add new varaible RUST_ENABLE_EXTRA_TOOLS"
+-  rust: add reproducibility patch to eliminate host leakage
+-  rust: build the default set of tools
+-  rust: correctly link rust-snapshot into build/stage0
+-  rust: use rust-snapshot binaries only in rust-native
+-  sanity.bbclass: skip check_userns for non-local uid
+-  scripts/install-buildtools: Update to 5.0.6
+-  system-requirements.rst: add dependencies for pdf builds
+-  system-requirements: add fedora 39 to supported distros
+-  system-requirements: update list of supported distros
+-  systemd: enable create-log-dirs
+-  test-manual/reproducible-builds: fix reproducible links
+
+
+Known Issues in Yocto-5.0.7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+Contributors to Yocto-5.0.7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+-  Aleksandar Nikolic
+-  Alexander Kanavin
+-  Alexis Lothoré
+-  Antonin Godard
+-  Archana Polampalli
+-  Bruce Ashfield
+-  Catalin Popescu
+-  Changqing Li
+-  Chen Qi
+-  Chris Laplante
+-  Divya Chellam
+-  Esben Haabendal
+-  Guénaël Muller
+-  Guðni Már Gilbert
+-  Harish Sadineni
+-  Hiago De Franco
+-  Hitendra Prajapati
+-  Jiaying Song
+-  Khem Raj
+-  Lee Chee Yang
+-  Mark Hatle
+-  Michael Opdenacker
+-  Mikko Rapeli
+-  Peter Marko
+-  Richard Purdie
+-  Robert Yang
+-  Ross Burton
+-  Soumya Sambu
+-  Steve Sakoman
+-  Sunil Dora
+-  Trevor Gamblin
+-  Xiangyu Chen
+-  Yash Shinde
+-  Zhang Peng
+-  Zahir Hussain
+
+
+Repositories / Downloads for Yocto-5.0.7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`scarthgap </poky/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.7 </poky/log/?h=yocto-5.0.7>`
+-  Git Revision: :yocto_git:`7dad83c7e5e9637c0ff5d5712409611fd4a14946 </poky/commit/?id=7dad83c7e5e9637c0ff5d5712409611fd4a14946>`
+-  Release Artefact: poky-7dad83c7e5e9637c0ff5d5712409611fd4a14946
+-  sha: ae688031b19b88582bb4a76d0525e3704b981ad1d21eb38a0873cd01dd9a4652
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.7/poky-7dad83c7e5e9637c0ff5d5712409611fd4a14946.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.7/poky-7dad83c7e5e9637c0ff5d5712409611fd4a14946.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`scarthgap </openembedded-core/log/?h=scarthgap>`
+-  Tag:  :oe_git:`yocto-5.0.7 </openembedded-core/log/?h=yocto-5.0.7>`
+-  Git Revision: :oe_git:`62cb12967391db709315820d48853ffa4c6b4740 </openembedded-core/commit/?id=62cb12967391db709315820d48853ffa4c6b4740>`
+-  Release Artefact: oecore-62cb12967391db709315820d48853ffa4c6b4740
+-  sha: bc45429df1805445b678f1b0ed6ce017edfac38c7226dce92ce393b3ef311f95
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.7/oecore-62cb12967391db709315820d48853ffa4c6b4740.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.7/oecore-62cb12967391db709315820d48853ffa4c6b4740.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`scarthgap </meta-mingw/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.7 </meta-mingw/log/?h=yocto-5.0.7>`
+-  Git Revision: :yocto_git:`acbba477893ef87388effc4679b7f40ee49fc852 </meta-mingw/commit/?id=acbba477893ef87388effc4679b7f40ee49fc852>`
+-  Release Artefact: meta-mingw-acbba477893ef87388effc4679b7f40ee49fc852
+-  sha: 3b7c2f475dad5130bace652b150367f587d44b391218b1364a8bbc430b48c54c
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.7/meta-mingw-acbba477893ef87388effc4679b7f40ee49fc852.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.7/meta-mingw-acbba477893ef87388effc4679b7f40ee49fc852.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.8 </bitbake/log/?h=2.8>`
+-  Tag:  :oe_git:`yocto-5.0.7 </bitbake/log/?h=yocto-5.0.7>`
+-  Git Revision: :oe_git:`aa0e540fc31a1c26839efd2c7785a751ce24ebfb </bitbake/commit/?id=aa0e540fc31a1c26839efd2c7785a751ce24ebfb>`
+-  Release Artefact: bitbake-aa0e540fc31a1c26839efd2c7785a751ce24ebfb
+-  sha: 169b68ed7d5e55015b1c35a82d35efaa25c87cba4722c85e66514a15d31e1d28
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.7/bitbake-aa0e540fc31a1c26839efd2c7785a751ce24ebfb.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.7/bitbake-aa0e540fc31a1c26839efd2c7785a751ce24ebfb.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`scarthgap </yocto-docs/log/?h=scarthgap>`
+-  Tag: :yocto_git:`yocto-5.0.7 </yocto-docs/log/?h=yocto-5.0.7>`
+-  Git Revision: :yocto_git:`bb9e018adcc10c642f87d0b95432783b5eb8057b </yocto-docs/commit/?id=bb9e018adcc10c642f87d0b95432783b5eb8057b>`
+

documentation/ref-manual/classes.rst

@@ -563,7 +563,7 @@ You can also look for vulnerabilities in specific packages by passing
 ``-c cve_check`` to BitBake.
 
 After building the software with Bitbake, CVE check output reports are available in ``tmp/deploy/cve``
-and image specific summaries in ``tmp/deploy/images/*.cve`` or ``tmp/deploy/images/*.json`` files.
+and image specific summaries in ``tmp/deploy/images/*.json`` files.
 
 When building, the CVE checker will emit build time warnings for any detected
 issues which are in the state ``Unpatched``, meaning that CVE issue seems to affect the software component

documentation/ref-manual/faq.rst

@@ -45,6 +45,28 @@ See :yocto_wiki:`Products that use the Yocto Project
 Wiki. Don't hesitate to contribute to this page if you know other such
 products.
 
+Why isn't systemd the default init system for OpenEmbedded-Core/Yocto Project or in Poky?
+-----------------------------------------------------------------------------------------
+
+`systemd <https://systemd.io/>`__ is a desktop Linux init system with a specific
+focus that is not entirely aligned with a customisable "embedded" build
+system/environment.
+
+It understandably mandates certain layouts and configurations which may
+or may not align with what the objectives and direction :term:`OpenEmbedded-Core
+(OE-Core)` or Yocto Project want to take. It doesn't support all of our targets.
+For example `musl <https://www.musl-libc.org/>`__ support in systemd is
+problematic.
+
+If it were our default, we would have to align with all their choices
+and this doesn't make sense. It is therefore a configuration option and
+available to anyone where the design goals align. But we are clear it
+is not the only way to handle init.
+
+Our automated testing includes it through the ``poky-altcfg`` :term:`DISTRO` and
+we don't really need it to be the default: it is tested, it works, and people
+can choose to use it.
+
 Building environment
 ====================
 

documentation/ref-manual/features.rst

@@ -12,7 +12,7 @@ Features provide a mechanism for working out which packages should be
 included in the generated images. Distributions can select which
 features they want to support through the :term:`DISTRO_FEATURES` variable,
 which is set or appended to in a distribution's configuration file such
-as ``poky.conf``, ``poky-tiny.conf``, ``poky-lsb.conf`` and so forth.
+as ``poky.conf``, ``poky-tiny.conf``, ``poky-altcfg.conf`` and so forth.
 Machine features are set in the :term:`MACHINE_FEATURES` variable, which is
 set in the machine configuration file and specifies the hardware
 features for a given machine.

documentation/ref-manual/images.rst

@@ -51,27 +51,6 @@ Here is a list of supported recipes:
 -  ``core-image-full-cmdline``: A console-only image with more
    full-featured Linux system functionality installed.
 
--  ``core-image-lsb``: An image that conforms to the Linux Standard Base
-   (LSB) specification. This image requires a distribution configuration
-   that enables LSB compliance (e.g. ``poky-lsb``). If you build
-   ``core-image-lsb`` without that configuration, the image will not be
-   LSB-compliant.
-
--  ``core-image-lsb-dev``: A ``core-image-lsb`` image that is suitable
-   for development work using the host. The image includes headers and
-   libraries you can use in a host development environment. This image
-   requires a distribution configuration that enables LSB compliance
-   (e.g. ``poky-lsb``). If you build ``core-image-lsb-dev`` without that
-   configuration, the image will not be LSB-compliant.
-
--  ``core-image-lsb-sdk``: A ``core-image-lsb`` that includes everything
-   in the cross-toolchain but also includes development headers and
-   libraries to form a complete standalone SDK. This image requires a
-   distribution configuration that enables LSB compliance (e.g.
-   ``poky-lsb``). If you build ``core-image-lsb-sdk`` without that
-   configuration, the image will not be LSB-compliant. This image is
-   suitable for development using the target.
-
 -  ``core-image-minimal``: A small image just capable of allowing a
    device to boot.
 

documentation/ref-manual/variables.rst

@@ -3902,6 +3902,12 @@ system and gives an overview of their function and contents.
 
          IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
 
+   :term:`IMAGE_ROOTFS_MAXSIZE`
+      Defines the maximum size in Kbytes for the generated image. If the
+      generated image size is above that, the build will fail. It's a good
+      idea to set this variable for images that need to fit on a limited
+      space (e.g. SD card, a fixed-size partition, ...).
+
    :term:`IMAGE_ROOTFS_SIZE`
       Defines the size in Kbytes for the generated image. The OpenEmbedded
       build system determines the final size for the generated image using
@@ -5638,14 +5644,6 @@ system and gives an overview of their function and contents.
 
          OECMAKE_GENERATOR = "Unix Makefiles"
 
-   :term:`OE_IMPORTS`
-      An internal variable used to tell the OpenEmbedded build system what
-      Python modules to import for every Python function run by the system.
-
-      .. note::
-
-         Do not set this variable. It is for internal use only.
-
    :term:`OE_INIT_ENV_SCRIPT`
       The name of the build environment setup script for the purposes of
       setting up the environment within the extensible SDK. The default

documentation/sdk-manual/extensible.rst

@@ -178,7 +178,7 @@ Running the Extensible SDK Environment Setup Script
 Once you have the SDK installed, you must run the SDK environment setup
 script before you can actually use the SDK.
 
-When using a SDK directly in a Yocto build, you will find the script in
+When using an SDK directly in a Yocto build, you will find the script in
 ``tmp/deploy/images/qemux86-64/`` in your :term:`Build Directory`.
 
 When using a standalone SDK installer, this setup script resides in
@@ -622,28 +622,91 @@ command:
       decide you do not want to proceed with your work. If you do use this
       command, realize that the source tree is preserved.
 
-``devtool ide-sdk`` configures IDEs for the extensible SDK
-----------------------------------------------------------
+``devtool ide-sdk`` configures IDEs and bootstraps SDKs
+-------------------------------------------------------
 
-``devtool ide-sdk`` automatically configures IDEs to use the extensible SDK.
-To make sure that all parts of the extensible SDK required by the generated
-IDE configuration are available, ``devtool ide-sdk`` uses BitBake in the
-background to bootstrap the extensible SDK.
+The ``devtool ide-sdk`` command can provide an IDE configuration for IDEs when
+working on the source code of one or more recipes.
+Depending on the programming language, and the build system used by the recipe,
+the tools required for cross-development and remote debugging are different.
+For example:
 
-The extensible SDK supports two different development modes.
-``devtool ide-sdk`` supports both of them:
+-  A C/C++ project usually uses CMake or Meson.
+
+-  A Python project uses setuptools or one of its successors.
+
+-  A Rust project uses Cargo.
+
+Also, the IDE plugins needed for the integration of a build system with the
+IDE and the corresponding settings are usually specific to these build-systems.
+To hide all these details from the user, ``devtool ide-sdk`` does two things:
+
+-  It generates any kind of SDK needed for cross-development and remote
+   debugging of the specified recipes.
+
+-  It generates the configuration for the IDE (and the IDE plugins) for using
+   the cross-toolchain and remote debugging tools provided by the SDK directly
+   from the IDE.
+
+For supported build systems the configurations generated by ``devtool ide-sdk``
+combine the advantages of the ``devtool modify`` based workflow
+(see :ref:`using_devtool`) with the advantages of the simple Environment Setup
+script based workflow (see :ref:`running_the_ext_sdk_env`) provided by Yocto's
+SDK or eSDK:
+
+-  The source code of the recipe is in the workspace created by
+   ``devtool modify`` or ``devtool add``.
+   Using ``devtool build``, ``devtool build-image``,
+   ``devtool deploy-target`` or ``bitbake`` is possible.
+   Also ``devtool ide-sdk`` can be used to update the SDK and the IDE
+   configuration at any time.
+
+-  ``devtool ide-sdk`` aims to support multiple programming languages and
+   multiple IDEs natively. "Natively" means that the IDE is configured to call
+   the build tool (e.g. ``cmake`` or ``meson``) directly. This has several
+   advantages.
+   First of all, it is usually much faster to call for example ``cmake`` than
+   ``devtool build``.
+   It also allows to benefit from the very good integration that IDEs like
+   VSCode offer for tools like CMake or GDB.
+   
+   However, supporting many programming languages and multiple
+   IDEs is quite an elaborate and constantly evolving thing. Support for IDEs
+   is therefore implemented as plugins. Plugins can also be provided by
+   optional layers.
+
+So much about the introduction to the default mode of ``devtool sdk-ide`` which
+is called the "modified" mode because it uses the workspace created by
+``devtool modify`` and the per recipe :term:`Sysroots <Sysroot>` of BitBake.
+
+For some recipes and use cases, this default behavior of ``devtool ide-sdk``
+with full ``devtool`` and ``bitbake`` integration might not be suitable.
+To offer full feature parity with the SDK and the eSDK, ``devtool ide-sdk`` has
+a second mode called "shared" mode.
+If ``devtool ide-sdk`` is called with the ``--mode=shared`` option, it
+bootstraps an SDK directly from the BitBake environment, which offers the same
+Environment Setup script as described in :ref:`running_the_ext_sdk_env`.
+In addition to the (e)SDK installer-based setup, the IDE gets configured
+to use the shared :term:`Sysroots <Sysroot>` and the tools from the SDK.
+``devtool ide-sdk --mode=shared`` is basically a wrapper for the setup of the
+extensible SDK as described in :ref:`setting_up_ext_sdk_in_build`.
+
+The use of ``devtool ide-sdk`` is an alternative to using one of the SDK
+installers.
+``devtool ide-sdk`` allows the creation of SDKs that offer all the
+functionality of the SDK and the eSDK installers. Compared to the installers,
+however, the SDK created with ``devtool ide-sdk`` is much more flexible.
+For example, it is very easy to change the :term:`MACHINE` in the
+``local.conf`` file, update the layer meta data and then regenerate the SDK.
+
+Let's take a look at an example of how to use ``devtool ide-sdk`` in each of
+the two modes:
 
 #. *Modified mode*:
 
-   By default ``devtool ide-sdk`` generates IDE configurations for recipes in
-   workspaces created by ``devtool modify`` or ``devtool add`` as described in
-   :ref:`using_devtool`.  This mode creates IDE configurations with support for
-   advanced features, such as deploying the binaries to the remote target
-   device and performing remote debugging sessions. The generated IDE
-   configurations use the per recipe sysroots as Bitbake does internally.
-
-   In order to use the tool, a few settings are needed. As a starting example,
-   the following lines of code can be added to the ``local.conf`` file::
+   In order to use the ``devtool ide-sdk``, a few settings are needed. As a
+   starting example, the following lines of code can be added to the
+   ``local.conf`` file::
 
       # Build the companion debug file system
       IMAGE_GEN_DEBUGFS = "1"
@@ -666,15 +729,20 @@ The extensible SDK supports two different development modes.
       IMAGE_INSTALL:append = " my-recipe"
 
    Assuming the BitBake environment is set up correctly and a workspace has
-   been created for the recipe using ``devtool modify my-recipe``, the
+   been created for the recipe using ``devtool modify my-recipe`` or probably
+   even better by using ``devtool modify my-recipe --debug-build``, the
    following command can create the SDK and the configuration for VSCode in
    the recipe workspace::
 
       $ devtool ide-sdk my-recipe core-image-minimal --target root@192.168.7.2
 
-   The command requires an image recipe (``core-image-minimal`` for this example)
-   that is used to create the SDK. This firmware image should also be installed
-   on the target device.  It is possible to pass multiple package recipes.
+   The command requires an image recipe (``core-image-minimal`` for this
+   example) that is used to create the SDK.
+   This firmware image should also be installed on the target device.
+   It is possible to pass multiple package recipes::
+
+      $ devtool ide-sdk my-recipe-1 my-recipe-2 core-image-minimal --target root@192.168.7.2
+
    ``devtool ide-sdk`` tries to create an IDE configuration for all package
    recipes.
 
@@ -684,9 +752,9 @@ The extensible SDK supports two different development modes.
 
    For example, a CMake preset is created for a recipe that inherits
    :ref:`ref-classes-cmake`. In the case of VSCode, CMake presets are supported
-   by the CMake Tools plugin.  This is an example of how the build
-   configuration used by ``bitbake`` is exported to an IDE configuration that
-   gives exactly the same build results.
+   by the CMake Tools plugin. This is an example of how the build configuration
+   used by ``bitbake`` is exported to an IDE configuration that gives exactly
+   the same build results.
 
    Support for remote debugging with seamless integration into the IDE is
    important for a cross-SDK. ``devtool ide-sdk`` automatically generates the
@@ -699,23 +767,54 @@ The extensible SDK supports two different development modes.
       running on the target device, it is essential that the image built by
       ``devtool ide-sdk`` is running on the target device.
 
-   ``devtool ide-sdk`` aims to support multiple programming languages and
-   multiple IDEs natively. "Natively" means that the IDE is configured to call
-   the build tool (e.g. CMake or Meson) directly. This has several advantages.
-   First of all, it is much faster than ``devtool build``, but it also allows
-   to use the very good integration of tools like CMake or GDB in VSCode and
-   other IDEs. However, supporting many programming languages and multiple
-   IDEs is quite an elaborate and constantly evolving thing. Support for IDEs
-   is therefore implemented as plugins. Plugins can also be provided by
-   optional layers.
-
    The default IDE is VSCode. Some hints about using VSCode:
 
-   -  To work on the source code of a recipe an instance of VSCode is started in
-      the recipe's workspace. Example::
+   -  VSCode can be used to work on the BitBake recipes or the application
+      source code.
+      Usually there is one instance of VSCode running in the folder where the
+      BitBake recipes are. This instance has the
+      `Yocto Project BitBake plugin <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`_
+      running.
+
+      .. warning::
+
+         Some VSCode plugins (Python, BitBake and others) need a reasonable
+         configuration to work as expected. Otherwise, some plugins try to
+         index the build directory of BitBake, which keeps your system quite
+         busy until an out of memory exception stops this nonsense.
+         Other plugins, such as the BitBake plugin, do not behave as expected.
+
+         To work around such issues, the ``oe-init-build-env`` script creates
+         an initial ``.vscode/settings.json`` file if ``code`` can be found
+         and the ``.vscode`` folder does not yet exist.
+         It is best to run ``oe-init-build-env`` once before starting VSCode.
+         An alternative approach is to use a build folder outside the layers,
+         e.g. ``oe-init-build-env ../build``.
+
+      The BitBake plugin also offers to create devtool workspaces and run
+      ``devtool ide-sdk`` with a few mouse clicks.
+      Of course, issuing commands in the terminal works as well.
+
+   -  To work on the source code of a recipe another instance of VSCode is
+      started in the recipe's workspace. Example::
 
          code build/workspace/sources/my-recipe
 
+      This instance of VSCode uses plugins that are useful for the development
+      of the application. ``devtool ide-sdk`` generates the necessary
+      ``extensions.json``, ``settings.json``, ``tasks.json``and ``launch.json``
+      configuration files for all the involved plugins.
+
+      When the source code folder present in the workspace folder is opened in
+      VSCode for the first time, a pop-up message recommends installing the
+      required plugins.
+      After accepting the installation of the plugins, working with the source
+      code or some debugging tasks should work as usual with VSCode.
+
+      Starting the VSCode instances in the recipe workspace folders can also be
+      done by a mouse click on the recipe workspaces in the first VSCode
+      instance.
+
    -  To work with CMake press ``Ctrl + Shift + p``, type ``cmake``. This will
       show some possible commands like selecting a CMake preset, compiling or
       running CTest.
@@ -728,10 +827,9 @@ The extensible SDK supports two different development modes.
       show some possible commands like compiling or executing the unit tests.
 
       A note on running cross-compiled unit tests on the host: Meson enables
-      support for QEMU user-mode by default. It is expected that the execution
-      of the unit tests from the IDE will work easily without any additional
-      steps, provided that the code is suitable for execution on the host
-      machine.
+      support for QEMU user mode by default. It is expected that the execution
+      of the unit tests from the IDE will work without any additional steps,
+      given that the code is suitable for the execution on the host machine.
 
    -  For the deployment to the target device, just press ``Ctrl + Shift + p``,
       type ``task``.  Select ``install && deploy-target``.
@@ -742,23 +840,23 @@ The extensible SDK supports two different development modes.
       selected.  After selecting one of the generated configurations, press the
       "play" button.
 
-      Starting a remote debugging session automatically initiates the deployment
-      to the target device. If this is not desired, the
+      Starting a remote debugging session automatically initiates the
+      deployment to the target device. If this is not desired, the
       ``"dependsOn": ["install && deploy-target...]`` parameter of the tasks
       with ``"label": "gdbserver start...`` can be removed from the
       ``tasks.json`` file.
 
-      VSCode supports GDB with many different setups and configurations for many
-      different use cases.  However, most of these setups have some limitations
-      when it comes to cross-development, support only a few target
+      VSCode supports GDB with many different setups and configurations for
+      many different use cases.  However, most of these setups have some
+      limitations when it comes to cross-development, support only a few target
       architectures or require a high performance target device. Therefore
       ``devtool ide-sdk`` supports the classic, generic setup with GDB on the
       development host and gdbserver on the target device.
 
       Roughly summarized, this means:
 
-      -  The binaries are copied via SSH to the remote target device by a script
-         referred by ``tasks.json``.
+      -  The binaries are copied via SSH to the remote target device by a
+         script referred by ``tasks.json``.
 
       -  gdbserver is started on the remote target device via SSH by a script
          referred by ``tasks.json``.
@@ -783,8 +881,8 @@ The extensible SDK supports two different development modes.
    .. code-block:: sh
 
       # Create the SDK
-      devtool modify cmake-example
-      devtool ide-sdk cmake-example core-image-minimal -c --debug-build-config --ide=none
+      devtool modify cmake-example --debug-build
+      devtool ide-sdk cmake-example core-image-minimal -c --ide=none
 
       # Install the firmware on a target device or start QEMU
       runqemu
@@ -860,16 +958,9 @@ The extensible SDK supports two different development modes.
 
 #. *Shared sysroots mode*
 
-   For some recipes and use cases a per-recipe sysroot based SDK is not
-   suitable.  Optionally ``devtool ide-sdk`` configures the IDE to use the
-   toolchain provided by the extensible SDK as described in
-   :ref:`running_the_ext_sdk_env`. ``devtool ide-sdk --mode=shared`` is
-   basically a wrapper for the setup of the extensible SDK as described in
-   :ref:`setting_up_ext_sdk_in_build`. The IDE gets a configuration to use the
-   shared sysroots.
-
-   Creating a SDK with shared sysroots that contains all the dependencies needed
-   to work with ``my-recipe`` is possible with the following example command::
+   Creating an SDK with shared :term:`Sysroots <Sysroot>` that contains all the
+   dependencies needed to work with ``my-recipe`` is possible with the following
+   example command::
 
       $ devtool ide-sdk --mode=shared my-recipe
 
@@ -883,12 +974,14 @@ The extensible SDK supports two different development modes.
       echo "project(foo VERSION 1.0)" > kit-test/CMakeLists.txt
       code kit-test
 
-   If there is a CMake project in the workspace, cross-compilation is supported:
+   If there is a CMake project in the workspace, cross-compilation is
+   supported:
 
    - Press ``Ctrl + Shift + P``, type ``CMake: Scan for Kits``
    - Press ``Ctrl + Shift + P``, type ``CMake: Select a Kit``
 
-   Finally most of the features provided by CMake and the IDE should be available.
+   Finally most of the features provided by CMake and the IDE should be
+   available.
 
    Other IDEs than VSCode are supported as well. However,
    ``devtool ide-sdk --mode=shared --ide=none my-recipe`` is currently

documentation/standards.md

@@ -1,6 +1,6 @@
 # Standards for contributing to Yocto Project documentation
 
-This document attemps to standardize the way the Yocto Project
+This document attempts to standardize the way the Yocto Project
 documentation is created.
 
 It is currently a work in progress.

documentation/test-manual/ptest.rst

@@ -61,6 +61,20 @@ test. Here is what you have to do for each recipe:
 
       inherit ptest
 
+   .. note::
+
+      Classes for common frameworks already exist in :term:`OpenEmbedded-Core
+      (OE-Core)`, such as:
+
+      -  :oe_git:`go-ptest </openembedded-core/tree/meta/classes-recipe/go-ptest.bbclass>`
+      -  :ref:`ref-classes-ptest-cargo`
+      -  :ref:`ref-classes-ptest-gnome`
+      -  :oe_git:`ptest-perl </openembedded-core/tree/meta/classes-recipe/ptest-perl.bbclass>`
+      -  :oe_git:`ptest-python-pytest </openembedded-core/tree/meta/classes-recipe/ptest-python-pytest.bbclass>`
+
+      Inheriting these classes with the ``inherit`` keyword in your recipe will
+      make the next steps automatic.
+
 -  *Create run-ptest:* This script starts your test. Locate the
    script where you will refer to it using
    :term:`SRC_URI`. Here is an

meta-poky/conf/distro/poky.conf

@@ -1,6 +1,6 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "5.0.7"
+DISTRO_VERSION = "5.0.8"
 DISTRO_CODENAME = "scarthgap"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}"
@@ -38,6 +38,7 @@ SANITY_TESTED_DISTROS ?= " \
             ubuntu-20.04 \n \
             ubuntu-22.04 \n \
             ubuntu-23.04 \n \
+            ubuntu-24.04 \n \
             fedora-38 \n \
             fedora-39 \n \
             fedora-40 \n \

meta/classes-recipe/cmake.bbclass

@@ -67,6 +67,8 @@ EXTRA_OECMAKE:append = " ${PACKAGECONFIG_CONFARGS}"
 export CMAKE_BUILD_PARALLEL_LEVEL
 CMAKE_BUILD_PARALLEL_LEVEL:task-compile = "${@oe.utils.parallel_make(d, False)}"
 CMAKE_BUILD_PARALLEL_LEVEL:task-install = "${@oe.utils.parallel_make(d, True)}"
+CMAKE_BUILD_PARALLEL_LEVEL:task-compile-ptest-base = "${@oe.utils.parallel_make(d, False)}"
+CMAKE_BUILD_PARALLEL_LEVEL:task-install-ptest-base = "${@oe.utils.parallel_make(d, True)}"
 
 OECMAKE_TARGET_COMPILE ?= "all"
 OECMAKE_TARGET_INSTALL ?= "install"

meta/classes-recipe/kernel-fitimage.bbclass

@@ -5,6 +5,7 @@
 #
 
 inherit kernel-uboot kernel-artifact-names uboot-config
+require conf/image-fitimage.conf
 
 def get_fit_replacement_type(d):
     kerneltypes = d.getVar('KERNEL_IMAGETYPES') or ""
@@ -52,58 +53,6 @@ python __anonymous () {
         d.setVar('EXTERNAL_KERNEL_DEVICETREE', "${RECIPE_SYSROOT}/boot/devicetree")
 }
 
-
-# Description string
-FIT_DESC ?= "Kernel fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
-
-# Kernel fitImage Hash Algo
-FIT_HASH_ALG ?= "sha256"
-
-# Kernel fitImage Signature Algo
-FIT_SIGN_ALG ?= "rsa2048"
-
-# Kernel / U-Boot fitImage Padding Algo
-FIT_PAD_ALG ?= "pkcs-1.5"
-
-# Generate keys for signing Kernel fitImage
-FIT_GENERATE_KEYS ?= "0"
-
-# Size of private keys in number of bits
-FIT_SIGN_NUMBITS ?= "2048"
-
-# args to openssl genrsa (Default is just the public exponent)
-FIT_KEY_GENRSA_ARGS ?= "-F4"
-
-# args to openssl req (Default is -batch for non interactive mode and
-# -new for new certificate)
-FIT_KEY_REQ_ARGS ?= "-batch -new"
-
-# Standard format for public key certificate
-FIT_KEY_SIGN_PKCS ?= "-x509"
-
-# Sign individual images as well
-FIT_SIGN_INDIVIDUAL ?= "0"
-
-FIT_CONF_PREFIX ?= "conf-"
-FIT_CONF_PREFIX[doc] = "Prefix to use for FIT configuration node name"
-
-FIT_SUPPORTED_INITRAMFS_FSTYPES ?= "cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.zst cpio.gz ext2.gz cpio"
-
-# Allow user to select the default DTB for FIT image when multiple dtb's exists.
-FIT_CONF_DEFAULT_DTB ?= ""
-
-# length of address in number of <u32> cells
-# ex: 1 32bits address, 2 64bits address
-FIT_ADDRESS_CELLS ?= "1"
-
-# Keys used to sign individually image nodes.
-# The keys to sign image nodes must be different from those used to sign
-# configuration nodes, otherwise the "required" property, from
-# UBOOT_DTB_BINARY, will be set to "conf", because "conf" prevails on "image".
-# Then the images signature checking will not be mandatory and no error will be
-# raised in case of failure.
-# UBOOT_SIGN_IMG_KEYNAME = "dev2" # keys name in keydir (eg. "dev2.crt", "dev2.key")
-
 #
 # Emit the fitImage ITS header
 #

meta/classes-recipe/rust-common.bbclass

@@ -13,7 +13,7 @@ FILES:${PN} += "${rustlibdir}/*.so"
 FILES:${PN}-dev += "${rustlibdir}/*.rlib ${rustlibdir}/*.rmeta"
 FILES:${PN}-dbg += "${rustlibdir}/.debug"
 
-RUSTLIB = "-L ${STAGING_DIR_HOST}${rustlibdir}"
+RUSTLIB ?= "-L ${STAGING_DIR_HOST}${rustlibdir}"
 RUST_DEBUG_REMAP = "--remap-path-prefix=${WORKDIR}=${TARGET_DBGSRC_DIR}"
 RUSTFLAGS += "${RUSTLIB} ${RUST_DEBUG_REMAP}"
 RUSTLIB_DEP ??= "libstd-rs"

meta/classes-recipe/uboot-config.bbclass

@@ -101,12 +101,12 @@ python () {
     # The "doc" varflag is special, we don't want to see it here
     ubootconfigflags.pop('doc', None)
     ubootconfig = (d.getVar('UBOOT_CONFIG') or "").split()
+    recipename = d.getVar("PN")
 
     if not ubootmachine and not ubootconfig:
-        PN = d.getVar("PN")
         FILE = os.path.basename(d.getVar("FILE"))
         bb.debug(1, "To build %s, see %s for instructions on \
-                 setting up your machine config" % (PN, FILE))
+                 setting up your machine config" % (recipename, FILE))
         raise bb.parse.SkipRecipe("Either UBOOT_MACHINE or UBOOT_CONFIG must be set in the %s machine configuration." % d.getVar("MACHINE"))
 
     if ubootmachine and ubootconfig:
@@ -140,9 +140,12 @@ python () {
             if not found:
                 raise bb.parse.SkipRecipe("The selected UBOOT_CONFIG key %s has no match in %s." % (ubootconfig, ubootconfigflags.keys()))
 
-            if len(ubootconfig) == 1:
-                d.setVar('KCONFIG_CONFIG_ROOTDIR', os.path.join(d.getVar("B"), d.getVar("UBOOT_MACHINE").strip()))
-            else:
-                # Disable menuconfig for multiple configs
-                d.setVar('KCONFIG_CONFIG_ENABLE_MENUCONFIG', "false")
+            # This recipe might be inherited e.g. by the kernel recipe via kernel-fitimage.bbclass
+            # Ensure the uboot specific menuconfig settings do not leak into other recipes
+            if 'u-boot' in recipename:
+                if len(ubootconfig) == 1:
+                    d.setVar('KCONFIG_CONFIG_ROOTDIR', os.path.join(d.getVar("B"), d.getVar("UBOOT_MACHINE").strip()))
+                else:
+                    # Disable menuconfig for multiple configs
+                    d.setVar('KCONFIG_CONFIG_ENABLE_MENUCONFIG', "false")
 }

meta/classes-recipe/uboot-sign.bbclass

@@ -26,6 +26,7 @@
 
 # We need some variables from u-boot-config
 inherit uboot-config
+require conf/image-fitimage.conf
 
 # Enable use of a U-Boot fitImage
 UBOOT_FITIMAGE_ENABLE ?= "0"
@@ -85,9 +86,6 @@ UBOOT_FIT_KEY_SIGN_PKCS ?= "-x509"
 # ex: 1 32bits address, 2 64bits address
 UBOOT_FIT_ADDRESS_CELLS ?= "1"
 
-# This is only necessary for determining the signing configuration
-KERNEL_PN = "${PREFERRED_PROVIDER_virtual/kernel}"
-
 UBOOT_FIT_UBOOT_LOADADDRESS ?= "${UBOOT_LOADADDRESS}"
 UBOOT_FIT_UBOOT_ENTRYPOINT ?= "${UBOOT_ENTRYPOINT}"
 
@@ -96,8 +94,6 @@ python() {
     sign = d.getVar('UBOOT_SIGN_ENABLE') == '1'
     if d.getVar('UBOOT_FITIMAGE_ENABLE') == '1' or sign:
         d.appendVar('DEPENDS', " u-boot-tools-native dtc-native")
-    if sign:
-        d.appendVar('DEPENDS', " " + d.getVar('KERNEL_PN'))
 }
 
 concat_dtb() {
@@ -105,17 +101,69 @@ concat_dtb() {
 	binary="$2"
 
 	if [ -e "${UBOOT_DTB_BINARY}" ]; then
-		# Re-sign the kernel in order to add the keys to our dtb
+		# Signing individual images is not recommended as that
+		# makes fitImage susceptible to mix-and-match attack.
+		#
+		# OE FIT_SIGN_INDIVIDUAL is implemented in an unusual manner,
+		# where the resulting signed fitImage contains both signed
+		# images and signed configurations. This is redundant. In
+		# order to prevent mix-and-match attack, it is sufficient
+		# to sign configurations. The FIT_SIGN_INDIVIDUAL = "1"
+		# support is kept to avoid breakage of existing layers, but
+		# it is highly recommended to avoid FIT_SIGN_INDIVIDUAL = "1",
+		# i.e. set FIT_SIGN_INDIVIDUAL = "0" .
+		if [ "${FIT_SIGN_INDIVIDUAL}" = "1" ] ; then
+			# Sign dummy image images in order to
+			# add the image signing keys to our dtb
+			${UBOOT_MKIMAGE_SIGN} \
+				${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
+				-f auto \
+				-k "${UBOOT_SIGN_KEYDIR}" \
+				-o "${FIT_HASH_ALG},${FIT_SIGN_ALG}" \
+				-g "${UBOOT_SIGN_IMG_KEYNAME}" \
+				-K "${UBOOT_DTB_BINARY}" \
+				-d /dev/null \
+				-r ${B}/unused.itb \
+				${UBOOT_MKIMAGE_SIGN_ARGS}
+		fi
+
+		# Sign dummy image configurations in order to
+		# add the configuration signing keys to our dtb
 		${UBOOT_MKIMAGE_SIGN} \
 			${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
-			-F -k "${UBOOT_SIGN_KEYDIR}" \
+			-f auto-conf \
+			-k "${UBOOT_SIGN_KEYDIR}" \
+			-o "${FIT_HASH_ALG},${FIT_SIGN_ALG}" \
+			-g "${UBOOT_SIGN_KEYNAME}" \
 			-K "${UBOOT_DTB_BINARY}" \
-			-r ${B}/fitImage-linux \
+			-d /dev/null \
+			-r ${B}/unused.itb \
 			${UBOOT_MKIMAGE_SIGN_ARGS}
-		# Verify the kernel image and u-boot dtb
-		${UBOOT_FIT_CHECK_SIGN} \
-			-k "${UBOOT_DTB_BINARY}" \
-			-f ${B}/fitImage-linux
+
+		# Verify the dummy fitImage signature against u-boot.dtb
+		# augmented using public key material.
+		#
+		# This only works for FIT_SIGN_INDIVIDUAL = "0", because
+		# mkimage -f auto-conf does not support -F to extend the
+		# existing unused.itb , and instead rewrites unused.itb
+		# from scratch.
+		#
+		# Using two separate unused.itb for mkimage -f auto and
+		# mkimage -f auto-conf invocation above would not help, as
+		# the signature verification process below checks whether
+		# all keys inserted into u-boot.dtb /signature node pass
+		# the verification. Separate unused.itb would each miss one
+		# of the signatures.
+		#
+		# The FIT_SIGN_INDIVIDUAL = "1" support is kept to avoid
+		# breakage of existing layers, but it is highly recommended
+		# to not use FIT_SIGN_INDIVIDUAL = "1", i.e. set
+		# FIT_SIGN_INDIVIDUAL = "0" .
+		if [ "${FIT_SIGN_INDIVIDUAL}" != "1" ] ; then
+			${UBOOT_FIT_CHECK_SIGN} \
+				-k "${UBOOT_DTB_BINARY}" \
+				-f ${B}/unused.itb
+		fi
 		cp ${UBOOT_DTB_BINARY} ${UBOOT_DTB_SIGNED}
 	fi
 
@@ -351,10 +399,6 @@ uboot_assemble_fitimage_helper() {
 }
 
 do_uboot_assemble_fitimage() {
-	if [ "${UBOOT_SIGN_ENABLE}" = "1" ] ; then
-		cp "${STAGING_DIR_HOST}/sysroot-only/fitImage" "${B}/fitImage-linux"
-	fi
-
 	if [ -n "${UBOOT_CONFIG}" ]; then
 		unset i
 		for config in ${UBOOT_MACHINE}; do

meta/conf/ccache.conf

@@ -1 +1,7 @@
 max_size = 0
+
+# Avoid spurious cache misses caused by recipe sysroot creation: Creating a
+# recipe sysroot hardlinks all dependent files into place. Hardlinking updates
+# the file's ctime which in turn interferes with ccache's include_file_ctime
+# check.
+sloppiness = include_file_ctime

meta/conf/image-fitimage.conf

@@ -0,0 +1,53 @@
+# Possible options for fitImage generation, mainly
+# related to signing of the fitImage content.
+
+# Description string
+FIT_DESC ?= "Kernel fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
+
+# Kernel fitImage Hash Algo
+FIT_HASH_ALG ?= "sha256"
+
+# Kernel fitImage Signature Algo
+FIT_SIGN_ALG ?= "rsa2048"
+
+# Kernel / U-Boot fitImage Padding Algo
+FIT_PAD_ALG ?= "pkcs-1.5"
+
+# Generate keys for signing Kernel fitImage
+FIT_GENERATE_KEYS ?= "0"
+
+# Size of private keys in number of bits
+FIT_SIGN_NUMBITS ?= "2048"
+
+# args to openssl genrsa (Default is just the public exponent)
+FIT_KEY_GENRSA_ARGS ?= "-F4"
+
+# args to openssl req (Default is -batch for non interactive mode and
+# -new for new certificate)
+FIT_KEY_REQ_ARGS ?= "-batch -new"
+
+# Standard format for public key certificate
+FIT_KEY_SIGN_PKCS ?= "-x509"
+
+# Sign individual images as well
+FIT_SIGN_INDIVIDUAL ?= "0"
+
+FIT_CONF_PREFIX ?= "conf-"
+FIT_CONF_PREFIX[doc] = "Prefix to use for FIT configuration node name"
+
+FIT_SUPPORTED_INITRAMFS_FSTYPES ?= "cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.zst cpio.gz ext2.gz cpio"
+
+# Allow user to select the default DTB for FIT image when multiple dtb's exists.
+FIT_CONF_DEFAULT_DTB ?= ""
+
+# length of address in number of <u32> cells
+# ex: 1 32bits address, 2 64bits address
+FIT_ADDRESS_CELLS ?= "1"
+
+# Keys used to sign individually image nodes.
+# The keys to sign image nodes must be different from those used to sign
+# configuration nodes, otherwise the "required" property, from
+# UBOOT_DTB_BINARY, will be set to "conf", because "conf" prevails on "image".
+# Then the images signature checking will not be mandatory and no error will be
+# raised in case of failure.
+# UBOOT_SIGN_IMG_KEYNAME = "dev2" # keys name in keydir (eg. "dev2.crt", "dev2.key")

meta/files/overlayfs-create-dirs.service.in

@@ -1,7 +1,6 @@
 [Unit]
-Description=Overlayfs directories setup
-Requires={DATA_MOUNT_UNIT}
-After={DATA_MOUNT_UNIT}
+Description=Overlayfs directories setup {LOWERDIR}
+RequiresMountsFor={DATA_MOUNT_POINT}
 DefaultDependencies=no
 
 [Service]

meta/files/overlayfs-unit.mount.in

@@ -1,5 +1,5 @@
 [Unit]
-Description=Overlayfs mount unit
+Description=Overlayfs mount unit {LOWERDIR}
 Requires={CREATE_DIRS_SERVICE}
 After={CREATE_DIRS_SERVICE}
 

meta/files/toolchain-shar-extract.sh

@@ -1,6 +1,11 @@
 #!/bin/sh
 
 export LC_ALL=en_US.UTF-8
+
+# The pipefail option is now part of POSIX (POSIX.1-2024) and available in more
+# and more shells. Enable it if available to make the SDK installer more robust.
+(set -o pipefail 2> /dev/null) && set -o pipefail
+
 #Make sure at least one python is installed
 INIT_PYTHON=$(which python3 2>/dev/null )
 [ -z "$INIT_PYTHON" ] && INIT_PYTHON=$(which python2 2>/dev/null)

meta/lib/oeqa/sdk/context.py

@@ -41,11 +41,13 @@ class OESDKTestContext(OETestContext):
 
     def hasTargetPackage(self, pkg, multilib=False, regex=False):
         if multilib:
-            # match multilib according to sdk_env
-            mls = self.td.get('MULTILIB_VARIANTS', '').split()
-            for ml in mls:
-                if ('ml'+ml) in self.sdk_env:
-                    pkg = ml + '-' + pkg
+            stripped_sdk_env = os.path.basename(self.sdk_env)
+            if stripped_sdk_env.startswith('environment-setup-'):
+                # match multilib according to sdk_env
+                mls = self.td.get('MULTILIB_VARIANTS', '').split()
+                for ml in mls:
+                    if ('ml'+ml) in stripped_sdk_env:
+                        pkg = ml + '-' + pkg
         return self._hasPackage(self.target_pkg_manifest, pkg, regex=regex)
 
 class OESDKTestContextExecutor(OETestContextExecutor):

meta/lib/oeqa/selftest/cases/devtool.py

@@ -2493,7 +2493,7 @@ class DevtoolIdeSdkTests(DevtoolBase):
         self.track_for_cleanup(tempdir)
         self.add_command_to_tearDown('bitbake -c clean %s' % recipe_name)
 
-        result = runCmd('devtool modify %s -x %s' % (recipe_name, tempdir))
+        result = runCmd('devtool modify %s -x %s --debug-build' % (recipe_name, tempdir))
         self.assertExists(os.path.join(tempdir, build_file),
                           'Extracted source could not be found')
         self.assertExists(os.path.join(self.workspacedir, 'conf',

meta/lib/oeqa/selftest/cases/rust.py

@@ -3,6 +3,7 @@ import os
 import subprocess
 import time
 from oeqa.core.decorator import OETestTag
+from oeqa.core.decorator.data import skipIfArch
 from oeqa.core.case import OEPTestResultTestCase
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars, runqemu, Command
@@ -38,15 +39,12 @@ def parse_results(filename):
 @OETestTag("toolchain-user")
 @OETestTag("runqemu")
 class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
+
+    @skipIfArch(['mips', 'mips64'])
     def test_rust(self, *args, **kwargs):
         # Disable Rust Oe-selftest
         #self.skipTest("The Rust Oe-selftest is disabled.")
 
-        # Skip mips32 target since it is unstable with rust tests
-        machine = get_bb_var('MACHINE')
-        if machine == "qemumips":
-            self.skipTest("The mips32 target is skipped for Rust Oe-selftest.")
-
         # build remote-test-server before image build
         recipe = "rust"
         start_time = time.time()
@@ -210,9 +208,8 @@ class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
             tmpdir = get_bb_var("TMPDIR", "rust")
 
             # Set path for target-poky-linux-gcc, RUST_TARGET_PATH and hosttools.
-            cmd = " export PATH=%s/recipe-sysroot-native/usr/bin:$PATH;" % rustlibpath
-            cmd = cmd + " export TARGET_VENDOR=\"-poky\";"
-            cmd = cmd + " export PATH=%s/recipe-sysroot-native/usr/bin/%s:%s/hosttools:$PATH;" % (rustlibpath, tcpath, tmpdir)
+            cmd = "export TARGET_VENDOR=\"-poky\";"
+            cmd = cmd + " export PATH=%s/recipe-sysroot-native/usr/bin/python3-native:%s/recipe-sysroot-native/usr/bin:%s/recipe-sysroot-native/usr/bin/%s:%s/hosttools:$PATH;" % (rustlibpath, rustlibpath, rustlibpath, tcpath, tmpdir)
             cmd = cmd + " export RUST_TARGET_PATH=%s/rust-targets;" % rustlibpath
             # Trigger testing.
             cmd = cmd + " export TEST_DEVICE_ADDR=\"%s:12345\";" % qemu.ip

meta/recipes-bsp/u-boot/files/CVE-2024-57254.patch

@@ -0,0 +1,47 @@
+From 3f9deb424ecd6ecd50f165b42f0b0290d83853f5 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 2 Aug 2024 18:36:45 +0200
+Subject: [PATCH 1/8] squashfs: Fix integer overflow in sqfs_inode_size()
+
+A carefully crafted squashfs filesystem can exhibit an extremly large
+inode size and overflow the calculation in sqfs_inode_size().
+As a consequence, the squashfs driver will read from wrong locations.
+
+Fix by using __builtin_add_overflow() to detect the overflow.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+
+CVE: CVE-2024-57254
+Upstream-Status: Backport [https://source.denx.de/u-boot/u-boot/-/commit/c8e929e5758999933f9e905049ef2bf3fe6b140d]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ fs/squashfs/sqfs_inode.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/fs/squashfs/sqfs_inode.c b/fs/squashfs/sqfs_inode.c
+index d25cfb53..bb3ccd37 100644
+--- a/fs/squashfs/sqfs_inode.c
++++ b/fs/squashfs/sqfs_inode.c
+@@ -78,11 +78,16 @@ int sqfs_inode_size(struct squashfs_base_inode *inode, u32 blk_size)
+ 
+ 	case SQFS_SYMLINK_TYPE:
+ 	case SQFS_LSYMLINK_TYPE: {
++		int size;
++
+ 		struct squashfs_symlink_inode *symlink =
+ 			(struct squashfs_symlink_inode *)inode;
+ 
+-		return sizeof(*symlink) +
+-			get_unaligned_le32(&symlink->symlink_size);
++		if (__builtin_add_overflow(sizeof(*symlink),
++		    get_unaligned_le32(&symlink->symlink_size), &size))
++			return -EINVAL;
++
++		return size;
+ 	}
+ 
+ 	case SQFS_BLKDEV_TYPE:
+-- 
+2.34.1
+

meta/recipes-bsp/u-boot/files/CVE-2024-57255.patch

@@ -0,0 +1,53 @@
+From 5d7ca74388544bf8c95e104517a9120e94bfe40d Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 2 Aug 2024 18:36:44 +0200
+Subject: [PATCH 2/8] squashfs: Fix integer overflow in sqfs_resolve_symlink()
+
+A carefully crafted squashfs filesystem can exhibit an inode size of 0xffffffff,
+as a consequence malloc() will do a zero allocation.
+Later in the function the inode size is again used for copying data.
+So an attacker can overwrite memory.
+Avoid the overflow by using the __builtin_add_overflow() helper.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+
+CVE: CVE-2024-57255
+Upstream-Status: Backport [https://source.denx.de/u-boot/u-boot/-/commit/233945eba63e24061dffeeaeb7cd6fe985278356]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ fs/squashfs/sqfs.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
+index 1430e671..16a07c06 100644
+--- a/fs/squashfs/sqfs.c
++++ b/fs/squashfs/sqfs.c
+@@ -422,8 +422,10 @@ static char *sqfs_resolve_symlink(struct squashfs_symlink_inode *sym,
+ 	char *resolved, *target;
+ 	u32 sz;
+ 
+-	sz = get_unaligned_le32(&sym->symlink_size);
+-	target = malloc(sz + 1);
++	if (__builtin_add_overflow(get_unaligned_le32(&sym->symlink_size), 1, &sz))
++		return NULL;
++
++	target = malloc(sz);
+ 	if (!target)
+ 		return NULL;
+ 
+@@ -431,9 +433,9 @@ static char *sqfs_resolve_symlink(struct squashfs_symlink_inode *sym,
+ 	 * There is no trailling null byte in the symlink's target path, so a
+ 	 * copy is made and a '\0' is added at its end.
+ 	 */
+-	target[sz] = '\0';
++	target[sz - 1] = '\0';
+ 	/* Get target name (relative path) */
+-	strncpy(target, sym->symlink, sz);
++	strncpy(target, sym->symlink, sz - 1);
+ 
+ 	/* Relative -> absolute path conversion */
+ 	resolved = sqfs_get_abs_path(base_path, target);
+-- 
+2.34.1
+

meta/recipes-bsp/u-boot/files/CVE-2024-57256.patch

@@ -0,0 +1,51 @@
+From 49cab731abe7a98db4ac16666e3b5ab3bc799282 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 9 Aug 2024 11:54:28 +0200
+Subject: [PATCH 3/8] ext4: Fix integer overflow in ext4fs_read_symlink()
+
+While zalloc() takes a size_t type, adding 1 to the le32 variable
+will overflow.
+A carefully crafted ext4 filesystem can exhibit an inode size of 0xffffffff
+and as consequence zalloc() will do a zero allocation.
+
+Later in the function the inode size is again used for copying data.
+So an attacker can overwrite memory.
+
+Avoid the overflow by using the __builtin_add_overflow() helper.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+
+CVE: CVE-2024-57256
+Upstream-Status: Backport [https://source.denx.de/u-boot/u-boot/-/commit/35f75d2a46e5859138c83a75cd2f4141c5479ab9]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ fs/ext4/ext4_common.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
+index f50de7c0..a7798296 100644
+--- a/fs/ext4/ext4_common.c
++++ b/fs/ext4/ext4_common.c
+@@ -2188,13 +2188,18 @@ static char *ext4fs_read_symlink(struct ext2fs_node *node)
+ 	struct ext2fs_node *diro = node;
+ 	int status;
+ 	loff_t actread;
++	size_t alloc_size;
+ 
+ 	if (!diro->inode_read) {
+ 		status = ext4fs_read_inode(diro->data, diro->ino, &diro->inode);
+ 		if (status == 0)
+ 			return NULL;
+ 	}
+-	symlink = zalloc(le32_to_cpu(diro->inode.size) + 1);
++
++	if (__builtin_add_overflow(le32_to_cpu(diro->inode.size), 1, &alloc_size))
++		return NULL;
++
++	symlink = zalloc(alloc_size);
+ 	if (!symlink)
+ 		return NULL;
+ 
+-- 
+2.34.1
+

meta/recipes-bsp/u-boot/files/CVE-2024-57257.patch

@@ -0,0 +1,227 @@
+From 4eb527c473068953f90ea65b33046a25140e0a89 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 2 Aug 2024 18:36:47 +0200
+Subject: [PATCH 4/8] squashfs: Fix stack overflow while symlink resolving
+
+The squashfs driver blindly follows symlinks, and calls sqfs_size()
+recursively. So an attacker can create a crafted filesystem and with
+a deep enough nesting level a stack overflow can be achieved.
+
+Fix by limiting the nesting level to 8.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+
+CVE: CVE-2024-57257
+Upstream-Status: Backport [https://source.denx.de/u-boot/u-boot/-/commit/4f5cc096bfd0a591f8a11e86999e3d90a9484c34]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ fs/squashfs/sqfs.c | 76 +++++++++++++++++++++++++++++++++++++---------
+ 1 file changed, 61 insertions(+), 15 deletions(-)
+
+diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
+index 16a07c06..a5b7890e 100644
+--- a/fs/squashfs/sqfs.c
++++ b/fs/squashfs/sqfs.c
+@@ -24,7 +24,12 @@
+ #include "sqfs_filesystem.h"
+ #include "sqfs_utils.h"
+ 
++#define MAX_SYMLINK_NEST 8
++
+ static struct squashfs_ctxt ctxt;
++static int symlinknest;
++
++static int sqfs_readdir_nest(struct fs_dir_stream *fs_dirs, struct fs_dirent **dentp);
+ 
+ static int sqfs_disk_read(__u32 block, __u32 nr_blocks, void *buf)
+ {
+@@ -508,7 +513,7 @@ static int sqfs_search_dir(struct squashfs_dir_stream *dirs, char **token_list,
+ 			goto out;
+ 		}
+ 
+-		while (!sqfs_readdir(dirsp, &dent)) {
++		while (!sqfs_readdir_nest(dirsp, &dent)) {
+ 			ret = strcmp(dent->name, token_list[j]);
+ 			if (!ret)
+ 				break;
+@@ -533,6 +538,11 @@ static int sqfs_search_dir(struct squashfs_dir_stream *dirs, char **token_list,
+ 
+ 		/* Check for symbolic link and inode type sanity */
+ 		if (get_unaligned_le16(&dir->inode_type) == SQFS_SYMLINK_TYPE) {
++			if (++symlinknest == MAX_SYMLINK_NEST) {
++				ret = -ELOOP;
++				goto out;
++			}
++
+ 			sym = (struct squashfs_symlink_inode *)table;
+ 			/* Get first j + 1 tokens */
+ 			path = sqfs_concat_tokens(token_list, j + 1);
+@@ -880,7 +890,7 @@ out:
+ 	return metablks_count;
+ }
+ 
+-int sqfs_opendir(const char *filename, struct fs_dir_stream **dirsp)
++static int sqfs_opendir_nest(const char *filename, struct fs_dir_stream **dirsp)
+ {
+ 	unsigned char *inode_table = NULL, *dir_table = NULL;
+ 	int j, token_count = 0, ret = 0, metablks_count;
+@@ -975,7 +985,19 @@ out:
+ 	return ret;
+ }
+ 
++int sqfs_opendir(const char *filename, struct fs_dir_stream **dirsp)
++{
++	symlinknest = 0;
++	return sqfs_opendir_nest(filename, dirsp);
++}
++
+ int sqfs_readdir(struct fs_dir_stream *fs_dirs, struct fs_dirent **dentp)
++{
++	symlinknest = 0;
++	return sqfs_readdir_nest(fs_dirs, dentp);
++}
++
++static int sqfs_readdir_nest(struct fs_dir_stream *fs_dirs, struct fs_dirent **dentp)
+ {
+ 	struct squashfs_super_block *sblk = ctxt.sblk;
+ 	struct squashfs_dir_stream *dirs;
+@@ -1319,8 +1341,8 @@ static int sqfs_get_lregfile_info(struct squashfs_lreg_inode *lreg,
+ 	return datablk_count;
+ }
+ 
+-int sqfs_read(const char *filename, void *buf, loff_t offset, loff_t len,
+-	      loff_t *actread)
++static int sqfs_read_nest(const char *filename, void *buf, loff_t offset,
++			  loff_t len, loff_t *actread)
+ {
+ 	char *dir = NULL, *fragment_block, *datablock = NULL;
+ 	char *fragment = NULL, *file = NULL, *resolved, *data;
+@@ -1350,11 +1372,11 @@ int sqfs_read(const char *filename, void *buf, loff_t offset, loff_t len,
+ 	}
+ 
+ 	/*
+-	 * sqfs_opendir will uncompress inode and directory tables, and will
++	 * sqfs_opendir_nest will uncompress inode and directory tables, and will
+ 	 * return a pointer to the directory that contains the requested file.
+ 	 */
+ 	sqfs_split_path(&file, &dir, filename);
+-	ret = sqfs_opendir(dir, &dirsp);
++	ret = sqfs_opendir_nest(dir, &dirsp);
+ 	if (ret) {
+ 		goto out;
+ 	}
+@@ -1362,7 +1384,7 @@ int sqfs_read(const char *filename, void *buf, loff_t offset, loff_t len,
+ 	dirs = (struct squashfs_dir_stream *)dirsp;
+ 
+ 	/* For now, only regular files are able to be loaded */
+-	while (!sqfs_readdir(dirsp, &dent)) {
++	while (!sqfs_readdir_nest(dirsp, &dent)) {
+ 		ret = strcmp(dent->name, file);
+ 		if (!ret)
+ 			break;
+@@ -1411,9 +1433,14 @@ int sqfs_read(const char *filename, void *buf, loff_t offset, loff_t len,
+ 		break;
+ 	case SQFS_SYMLINK_TYPE:
+ 	case SQFS_LSYMLINK_TYPE:
++		if (++symlinknest == MAX_SYMLINK_NEST) {
++			ret = -ELOOP;
++			goto out;
++		}
++
+ 		symlink = (struct squashfs_symlink_inode *)ipos;
+ 		resolved = sqfs_resolve_symlink(symlink, filename);
+-		ret = sqfs_read(resolved, buf, offset, len, actread);
++		ret = sqfs_read_nest(resolved, buf, offset, len, actread);
+ 		free(resolved);
+ 		goto out;
+ 	case SQFS_BLKDEV_TYPE:
+@@ -1584,7 +1611,14 @@ out:
+ 	return ret;
+ }
+ 
+-int sqfs_size(const char *filename, loff_t *size)
++int sqfs_read(const char *filename, void *buf, loff_t offset, loff_t len,
++	      loff_t *actread)
++{
++	symlinknest = 0;
++	return sqfs_read_nest(filename, buf, offset, len, actread);
++}
++
++static int sqfs_size_nest(const char *filename, loff_t *size)
+ {
+ 	struct squashfs_super_block *sblk = ctxt.sblk;
+ 	struct squashfs_symlink_inode *symlink;
+@@ -1600,10 +1634,10 @@ int sqfs_size(const char *filename, loff_t *size)
+ 
+ 	sqfs_split_path(&file, &dir, filename);
+ 	/*
+-	 * sqfs_opendir will uncompress inode and directory tables, and will
++	 * sqfs_opendir_nest will uncompress inode and directory tables, and will
+ 	 * return a pointer to the directory that contains the requested file.
+ 	 */
+-	ret = sqfs_opendir(dir, &dirsp);
++	ret = sqfs_opendir_nest(dir, &dirsp);
+ 	if (ret) {
+ 		ret = -EINVAL;
+ 		goto free_strings;
+@@ -1611,7 +1645,7 @@ int sqfs_size(const char *filename, loff_t *size)
+ 
+ 	dirs = (struct squashfs_dir_stream *)dirsp;
+ 
+-	while (!sqfs_readdir(dirsp, &dent)) {
++	while (!sqfs_readdir_nest(dirsp, &dent)) {
+ 		ret = strcmp(dent->name, file);
+ 		if (!ret)
+ 			break;
+@@ -1644,6 +1678,11 @@ int sqfs_size(const char *filename, loff_t *size)
+ 		break;
+ 	case SQFS_SYMLINK_TYPE:
+ 	case SQFS_LSYMLINK_TYPE:
++		if (++symlinknest == MAX_SYMLINK_NEST) {
++			*size = 0;
++			return -ELOOP;
++		}
++
+ 		symlink = (struct squashfs_symlink_inode *)ipos;
+ 		resolved = sqfs_resolve_symlink(symlink, filename);
+ 		ret = sqfs_size(resolved, size);
+@@ -1683,10 +1722,11 @@ int sqfs_exists(const char *filename)
+ 
+ 	sqfs_split_path(&file, &dir, filename);
+ 	/*
+-	 * sqfs_opendir will uncompress inode and directory tables, and will
++	 * sqfs_opendir_nest will uncompress inode and directory tables, and will
+ 	 * return a pointer to the directory that contains the requested file.
+ 	 */
+-	ret = sqfs_opendir(dir, &dirsp);
++	symlinknest = 0;
++	ret = sqfs_opendir_nest(dir, &dirsp);
+ 	if (ret) {
+ 		ret = -EINVAL;
+ 		goto free_strings;
+@@ -1694,7 +1734,7 @@ int sqfs_exists(const char *filename)
+ 
+ 	dirs = (struct squashfs_dir_stream *)dirsp;
+ 
+-	while (!sqfs_readdir(dirsp, &dent)) {
++	while (!sqfs_readdir_nest(dirsp, &dent)) {
+ 		ret = strcmp(dent->name, file);
+ 		if (!ret)
+ 			break;
+@@ -1711,6 +1751,12 @@ free_strings:
+ 	return ret == 0;
+ }
+ 
++int sqfs_size(const char *filename, loff_t *size)
++{
++	symlinknest = 0;
++	return sqfs_size_nest(filename, size);
++}
++
+ void sqfs_close(void)
+ {
+ 	sqfs_decompressor_cleanup(&ctxt);
+-- 
+2.34.1
+

meta/recipes-bsp/u-boot/files/CVE-2024-57258-1.patch

@@ -0,0 +1,47 @@
+From 50ab41c3628dedeca1a331dd86dd203b73faea74 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 2 Aug 2024 12:08:45 +0200
+Subject: [PATCH 5/8] dlmalloc: Fix integer overflow in sbrk()
+
+Make sure that the new break is within mem_malloc_start
+and mem_malloc_end before making progress.
+ulong new = old + increment; can overflow for extremely large
+increment values and memset() can get wrongly called.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reviewed-by: Simon Glass <sjg@chromium.org>
+
+CVE: CVE-2024-57258
+Upstream-Status: Backport [https://source.denx.de/u-boot/u-boot/-/commit/0a10b49206a29b4aa2f80233a3e53ca0466bb0b3]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ common/dlmalloc.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/common/dlmalloc.c b/common/dlmalloc.c
+index de3f0422..bae2a27c 100644
+--- a/common/dlmalloc.c
++++ b/common/dlmalloc.c
+@@ -591,6 +591,9 @@ void *sbrk(ptrdiff_t increment)
+ 	ulong old = mem_malloc_brk;
+ 	ulong new = old + increment;
+ 
++	if ((new < mem_malloc_start) || (new > mem_malloc_end))
++		return (void *)MORECORE_FAILURE;
++
+ 	/*
+ 	 * if we are giving memory back make sure we clear it out since
+ 	 * we set MORECORE_CLEARS to 1
+@@ -598,9 +601,6 @@ void *sbrk(ptrdiff_t increment)
+ 	if (increment < 0)
+ 		memset((void *)new, 0, -increment);
+ 
+-	if ((new < mem_malloc_start) || (new > mem_malloc_end))
+-		return (void *)MORECORE_FAILURE;
+-
+ 	mem_malloc_brk = new;
+ 
+ 	return (void *)old;
+-- 
+2.34.1
+

meta/recipes-bsp/u-boot/files/CVE-2024-57258-2.patch

@@ -0,0 +1,43 @@
+From db7c626204f488a802a2e58b7a788b11fde6be7d Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 2 Aug 2024 12:08:44 +0200
+Subject: [PATCH 6/8] dlmalloc: Fix integer overflow in request2size()
+
+req is of type size_t, casting it to long opens the door
+for an integer overflow.
+Values between LONG_MAX - (SIZE_SZ + MALLOC_ALIGN_MASK) - 1 and LONG_MAX
+cause and overflow such that request2size() returns MINSIZE.
+
+Fix by removing the cast.
+The origin of the cast is unclear, it's in u-boot and ppcboot since ever
+and predates the CVS history.
+Doug Lea's original dlmalloc implementation also doesn't have it.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reviewed-by: Simon Glass <sjg@chromium.org>
+
+CVE: CVE-2024-57258
+Upstream-Status: Backport [https://source.denx.de/u-boot/u-boot/-/commit/8642b2178d2c4002c99a0b69a845a48f2ae2706f]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ common/dlmalloc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/common/dlmalloc.c b/common/dlmalloc.c
+index bae2a27c..1ac4ee9f 100644
+--- a/common/dlmalloc.c
++++ b/common/dlmalloc.c
+@@ -379,8 +379,8 @@ nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ /* pad request bytes into a usable size */
+ 
+ #define request2size(req) \
+- (((long)((req) + (SIZE_SZ + MALLOC_ALIGN_MASK)) < \
+-  (long)(MINSIZE + MALLOC_ALIGN_MASK)) ? MINSIZE : \
++ ((((req) + (SIZE_SZ + MALLOC_ALIGN_MASK)) < \
++  (MINSIZE + MALLOC_ALIGN_MASK)) ? MINSIZE : \
+    (((req) + (SIZE_SZ + MALLOC_ALIGN_MASK)) & ~(MALLOC_ALIGN_MASK)))
+ 
+ /* Check if m has acceptable alignment */
+-- 
+2.34.1
+

meta/recipes-bsp/u-boot/files/CVE-2024-57258-3.patch

@@ -0,0 +1,40 @@
+From 37095a204127b60b5e00c4c5d435d6e48a6a1c51 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 2 Aug 2024 12:08:43 +0200
+Subject: [PATCH 7/8] x86: Fix ptrdiff_t for x86_64
+
+sbrk() assumes ptrdiff_t is large enough to enlarge/shrink the heap
+by LONG_MIN/LONG_MAX.
+So, use the long type, also to match the rest of the Linux ecosystem.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reviewed-by: Simon Glass <sjg@chromium.org>
+
+CVE: CVE-2024-57258
+Upstream-Status: Backport [https://source.denx.de/u-boot/u-boot/-/commit/c17b2a05dd50a3ba437e6373093a0d6a359cdee0]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ arch/x86/include/asm/posix_types.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h
+index dbcea7f4..e1ed9bca 100644
+--- a/arch/x86/include/asm/posix_types.h
++++ b/arch/x86/include/asm/posix_types.h
+@@ -20,11 +20,12 @@ typedef unsigned short	__kernel_gid_t;
+ #if defined(__x86_64__)
+ typedef unsigned long	__kernel_size_t;
+ typedef long		__kernel_ssize_t;
++typedef long		__kernel_ptrdiff_t;
+ #else
+ typedef unsigned int	__kernel_size_t;
+ typedef int		__kernel_ssize_t;
+-#endif
+ typedef int		__kernel_ptrdiff_t;
++#endif
+ typedef long		__kernel_time_t;
+ typedef long		__kernel_suseconds_t;
+ typedef long		__kernel_clock_t;
+-- 
+2.34.1
+

meta/recipes-bsp/u-boot/files/CVE-2024-57259.patch

@@ -0,0 +1,41 @@
+From 2c08fe306c6cbc60ec4beb434c71e56bb7abb678 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 2 Aug 2024 22:05:09 +0200
+Subject: [PATCH 8/8] squashfs: Fix heap corruption in sqfs_search_dir()
+
+res needs to be large enough to store both strings rem and target,
+plus the path separator and the terminator.
+Currently the space for the path separator is not accounted, so
+the heap is corrupted by one byte.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+
+CVE: CVE-2024-57259
+Upstream-Status: Backport [https://source.denx.de/u-boot/u-boot/-/commit/048d795bb5b3d9c5701b4855f5e74bcf6849bf5e]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ fs/squashfs/sqfs.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
+index a5b7890e..1bd9b2a4 100644
+--- a/fs/squashfs/sqfs.c
++++ b/fs/squashfs/sqfs.c
+@@ -563,8 +563,11 @@ static int sqfs_search_dir(struct squashfs_dir_stream *dirs, char **token_list,
+ 				ret = -ENOMEM;
+ 				goto out;
+ 			}
+-			/* Concatenate remaining tokens and symlink's target */
+-			res = malloc(strlen(rem) + strlen(target) + 1);
++			/*
++			 * Concatenate remaining tokens and symlink's target.
++			 * Allocate enough space for rem, target, '/' and '\0'.
++			 */
++			res = malloc(strlen(rem) + strlen(target) + 2);
+ 			if (!res) {
+ 				ret = -ENOMEM;
+ 				goto out;
+-- 
+2.34.1
+

meta/recipes-bsp/u-boot/u-boot-common.inc

@@ -14,7 +14,16 @@ PE = "1"
 # repo during parse
 SRCREV = "866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e"
 
-SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master"
+SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master \
+           file://CVE-2024-57254.patch \
+           file://CVE-2024-57255.patch \
+           file://CVE-2024-57256.patch \
+           file://CVE-2024-57257.patch \
+           file://CVE-2024-57258-1.patch \
+           file://CVE-2024-57258-2.patch \
+           file://CVE-2024-57258-3.patch \
+           file://CVE-2024-57259.patch \
+"
 
 S = "${WORKDIR}/git"
 B = "${WORKDIR}/build"

meta/recipes-connectivity/bind/bind_9.18.33.bb

@@ -20,7 +20,7 @@ SRC_URI = "https://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.xz \
            file://0001-avoid-start-failure-with-bind-user.patch \
            "
 
-SRC_URI[sha256sum] = "e7cce9a165f7b619eefc4832f0a8dc16b005d29e3890aed6008c506ea286a5e7"
+SRC_URI[sha256sum] = "fb373fac5ebbc41c645160afd5a9fb451918f6c0e69ab1d9474154e2b515de40"
 
 UPSTREAM_CHECK_URI = "https://ftp.isc.org/isc/bind9/"
 # follow the ESV versions divisible by 2

meta/recipes-connectivity/openssh/openssh/CVE-2025-26466.patch

@@ -0,0 +1,38 @@
+From 6ce00f0c2ecbb9f75023dbe627ee6460bcec78c2 Mon Sep 17 00:00:00 2001
+From: "djm@openbsd.org" <djm@openbsd.org>
+Date: Tue, 18 Feb 2025 08:02:12 +0000
+Subject: [PATCH] upstream: Don't reply to PING in preauth phase or during KEX
+
+Reported by the Qualys Security Advisory team. ok markus@
+
+OpenBSD-Commit-ID: c656ac4abd1504389d1733d85152044b15830217
+
+Upstream-Status: Backport [https://github.com/openssh/openssh-portable/commit/6ce00f0c2ecbb9f75023dbe627ee6460bcec78c2]
+CVE: CVE-2025-26466
+Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
+---
+ packet.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/packet.c b/packet.c
+index beb214f..aeab98c 100644
+--- a/packet.c
++++ b/packet.c
+@@ -1773,6 +1773,14 @@ ssh_packet_read_poll_seqnr(struct ssh *ssh, u_char *typep, u_int32_t *seqnr_p)
+ 			if ((r = sshpkt_get_string_direct(ssh, &d, &len)) != 0)
+ 				return r;
+ 			DBG(debug("Received SSH2_MSG_PING len %zu", len));
++			if (!ssh->state->after_authentication) {
++				DBG(debug("Won't reply to PING in preauth"));
++				break;
++			}
++			if (ssh_packet_is_rekeying(ssh)) {
++				DBG(debug("Won't reply to PING during KEX"));
++				break;
++			}
+ 			if ((r = sshpkt_start(ssh, SSH2_MSG_PONG)) != 0 ||
+ 			    (r = sshpkt_put_string(ssh, d, len)) != 0 ||
+ 			    (r = sshpkt_send(ssh)) != 0)
+-- 
+2.25.1
+

meta/recipes-connectivity/openssh/openssh_9.6p1.bb

@@ -29,6 +29,7 @@ SRC_URI = "http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
            file://CVE-2024-6387.patch \
            file://CVE-2024-39894.patch \
            file://0001-Fix-missing-header-for-systemd-notification.patch \
+           file://CVE-2025-26466.patch \
            "
 SRC_URI[sha256sum] = "910211c07255a8c5ad654391b40ee59800710dd8119dd5362de09385aa7a777c"
 

meta/recipes-connectivity/openssl/openssl/0001-Added-handshake-history-reporting-when-test-fails.patch

@@ -8,10 +8,10 @@ Upstream-Status: Submitted [https://github.com/openssl/openssl/pull/22481]
 Signed-off-by: William Lyu <William.Lyu@windriver.com>
 Signed-off-by: Siddharth Doshi <sdoshi@mvista.com>
 ---
- test/helpers/handshake.c | 139 +++++++++++++++++++++++++++++----------
+ test/helpers/handshake.c | 137 +++++++++++++++++++++++++++++----------
  test/helpers/handshake.h |  70 +++++++++++++++++++-
  test/ssl_test.c          |  44 +++++++++++++
- 3 files changed, 218 insertions(+), 35 deletions(-)
+ 3 files changed, 217 insertions(+), 34 deletions(-)
 
 diff --git a/test/helpers/handshake.c b/test/helpers/handshake.c
 index e0422469e4..ae2ad59dd4 100644
@@ -20,7 +20,7 @@ index e0422469e4..ae2ad59dd4 100644
 @@ -24,6 +24,102 @@
  #include <netinet/sctp.h>
  #endif
-
+ 
 +/* Shamelessly copied from test/helpers/ssl_test_ctx.c */
 +/* Maps string names to various enumeration type */
 +typedef struct {
@@ -120,10 +120,10 @@ index e0422469e4..ae2ad59dd4 100644
  HANDSHAKE_RESULT *HANDSHAKE_RESULT_new(void)
  {
      HANDSHAKE_RESULT *ret;
-@@ -719,15 +815,6 @@ static void configure_handshake_ssl(SSL *server, SSL *client,
+@@ -725,15 +821,6 @@ static void configure_handshake_ssl(SSL *server, SSL *client,
          SSL_set_post_handshake_auth(client, 1);
  }
-
+ 
 -/* The status for each connection phase. */
 -typedef enum {
 -    PEER_SUCCESS,
@@ -136,10 +136,10 @@ index e0422469e4..ae2ad59dd4 100644
  /* An SSL object and associated read-write buffers. */
  typedef struct peer_st {
      SSL *ssl;
-@@ -1074,17 +1161,6 @@ static void do_shutdown_step(PEER *peer)
+@@ -1080,17 +1167,6 @@ static void do_shutdown_step(PEER *peer)
      }
  }
-
+ 
 -typedef enum {
 -    HANDSHAKE,
 -    RENEG_APPLICATION_DATA,
@@ -154,10 +154,10 @@ index e0422469e4..ae2ad59dd4 100644
  static int renegotiate_op(const SSL_TEST_CTX *test_ctx)
  {
      switch (test_ctx->handshake_mode) {
-@@ -1162,19 +1238,6 @@ static void do_connect_step(const SSL_TEST_CTX *test_ctx, PEER *peer,
+@@ -1168,19 +1244,6 @@ static void do_connect_step(const SSL_TEST_CTX *test_ctx, PEER *peer,
      }
  }
-
+ 
 -typedef enum {
 -    /* Both parties succeeded. */
 -    HANDSHAKE_SUCCESS,
@@ -174,10 +174,10 @@ index e0422469e4..ae2ad59dd4 100644
  /*
   * Determine the handshake outcome.
   * last_status: the status of the peer to have acted last.
-@@ -1539,6 +1602,10 @@ static HANDSHAKE_RESULT *do_handshake_internal(
-
+@@ -1545,6 +1608,10 @@ static HANDSHAKE_RESULT *do_handshake_internal(
+ 
      start = time(NULL);
-
+ 
 +    save_loop_history(&(ret->history),
 +                      phase, status, server.status, client.status,
 +                      client_turn_count, client_turn);
@@ -185,10 +185,10 @@ index e0422469e4..ae2ad59dd4 100644
      /*
       * Half-duplex handshake loop.
       * Client and server speak to each other synchronously in the same process.
-@@ -1560,6 +1627,10 @@ static HANDSHAKE_RESULT *do_handshake_internal(
+@@ -1566,6 +1633,10 @@ static HANDSHAKE_RESULT *do_handshake_internal(
                                        0 /* server went last */);
          }
-
+ 
 +        save_loop_history(&(ret->history),
 +                          phase, status, server.status, client.status,
 +                          client_turn_count, client_turn);
@@ -208,9 +208,9 @@ index 78b03f9f4b..b9967c2623 100644
   * Licensed under the Apache License 2.0 (the "License").  You may not use
   * this file except in compliance with the License.  You can obtain a copy
 @@ -12,6 +12,11 @@
-
+ 
  #include "ssl_test_ctx.h"
-
+ 
 +#define MAX_HANDSHAKE_HISTORY_ENTRY_BIT 4
 +#define MAX_HANDSHAKE_HISTORY_ENTRY (1 << MAX_HANDSHAKE_HISTORY_ENTRY_BIT)
 +#define MAX_HANDSHAKE_HISTORY_ENTRY_IDX_MASK \
@@ -222,7 +222,7 @@ index 78b03f9f4b..b9967c2623 100644
 @@ -22,6 +27,63 @@ typedef struct ctx_data_st {
      char *session_ticket_app_data;
  } CTX_DATA;
-
+ 
 +typedef enum {
 +    HANDSHAKE,
 +    RENEG_APPLICATION_DATA,
@@ -290,12 +290,12 @@ index 78b03f9f4b..b9967c2623 100644
 +    /* handshake loop history */
 +    HANDSHAKE_HISTORY history;
  } HANDSHAKE_RESULT;
-
+ 
  HANDSHAKE_RESULT *HANDSHAKE_RESULT_new(void);
 @@ -95,4 +159,8 @@ int configure_handshake_ctx_for_srp(SSL_CTX *server_ctx, SSL_CTX *server2_ctx,
                                      CTX_DATA *server2_ctx_data,
                                      CTX_DATA *client_ctx_data);
-
+ 
 +const char *handshake_connect_phase_name(connect_phase_t phase);
 +const char *handshake_status_name(handshake_status_t handshake_status);
 +const char *handshake_peer_status_name(peer_status_t peer_status);
@@ -308,7 +308,7 @@ index ea608518f9..9d6b093c81 100644
 @@ -26,6 +26,44 @@ static OSSL_LIB_CTX *libctx = NULL;
  /* Currently the section names are of the form test-<number>, e.g. test-15. */
  #define MAX_TESTCASE_NAME_LENGTH 100
-
+ 
 +static void print_handshake_history(const HANDSHAKE_HISTORY *history)
 +{
 +    size_t first_idx;

meta/recipes-connectivity/openssl/openssl/0001-Configure-do-not-tweak-mips-cflags.patch

@@ -20,7 +20,7 @@ diff --git a/Configure b/Configure
 index 4569952..adf019b 100755
 --- a/Configure
 +++ b/Configure
-@@ -1422,16 +1422,6 @@ if ($target =~ /^mingw/ && `$config{CC} --target-help 2>&1` =~ m/-mno-cygwin/m)
+@@ -1485,16 +1485,6 @@ if ($target =~ /^mingw/ && `$config{CC} --target-help 2>&1` =~ m/-mno-cygwin/m)
          push @{$config{shared_ldflag}}, "-mno-cygwin";
          }
  

meta/recipes-connectivity/openssl/openssl/0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch

@@ -38,7 +38,7 @@ Index: openssl-3.0.4/Configurations/unix-Makefile.tmpl
 ===================================================================
 --- openssl-3.0.4.orig/Configurations/unix-Makefile.tmpl
 +++ openssl-3.0.4/Configurations/unix-Makefile.tmpl
-@@ -472,13 +472,23 @@ BIN_LDFLAGS={- join(' ', $target{bin_lfl
+@@ -481,13 +481,23 @@ BIN_LDFLAGS={- join(' ', $target{bin_lflags} || (),
                           '$(CNF_LDFLAGS)', '$(LDFLAGS)') -}
  BIN_EX_LIBS=$(CNF_EX_LIBS) $(EX_LIBS)
  
@@ -67,7 +67,7 @@ Index: openssl-3.0.4/crypto/build.info
 ===================================================================
 --- openssl-3.0.4.orig/crypto/build.info
 +++ openssl-3.0.4/crypto/build.info
-@@ -109,7 +109,7 @@ DEFINE[../libcrypto]=$UPLINKDEF
+@@ -115,7 +115,7 @@ DEFINE[../libcrypto]=$UPLINKDEF
  
  DEPEND[info.o]=buildinf.h
  DEPEND[cversion.o]=buildinf.h

meta/recipes-connectivity/openssl/openssl/CVE-2024-9143.patch

@@ -1,202 +0,0 @@
-From bc7e04d7c8d509fb78fc0e285aa948fb0da04700 Mon Sep 17 00:00:00 2001
-From: Viktor Dukhovni <viktor@openssl.org>
-Date: Thu, 19 Sep 2024 01:02:40 +1000
-Subject: [PATCH] Harden BN_GF2m_poly2arr against misuse.
-
-The BN_GF2m_poly2arr() function converts characteristic-2 field
-(GF_{2^m}) Galois polynomials from a representation as a BIGNUM bitmask,
-to a compact array with just the exponents of the non-zero terms.
-
-These polynomials are then used in BN_GF2m_mod_arr() to perform modular
-reduction.  A precondition of calling BN_GF2m_mod_arr() is that the
-polynomial must have a non-zero constant term (i.e. the array has `0` as
-its final element).
-
-Internally, callers of BN_GF2m_poly2arr() did not verify that
-precondition, and binary EC curve parameters with an invalid polynomial
-could lead to out of bounds memory reads and writes in BN_GF2m_mod_arr().
-
-The precondition is always true for polynomials that arise from the
-standard form of EC parameters for characteristic-two fields (X9.62).
-See the "Finite Field Identification" section of:
-
-    https://www.itu.int/ITU-T/formal-language/itu-t/x/x894/2018-cor1/ANSI-X9-62.html
-
-The OpenSSL GF(2^m) code supports only the trinomial and pentanomial
-basis X9.62 forms.
-
-This commit updates BN_GF2m_poly2arr() to return `0` (failure) when
-the constant term is zero (i.e. the input bitmask BIGNUM is not odd).
-
-Additionally, the return value is made unambiguous when there is not
-enough space to also pad the array with a final `-1` sentinel value.
-The return value is now always the number of elements (including the
-final `-1`) that would be filled when the output array is sufficiently
-large.  Previously the same count was returned both when the array has
-just enough room for the final `-1` and when it had only enough space
-for non-sentinel values.
-
-Finally, BN_GF2m_poly2arr() is updated to reject polynomials whose
-degree exceeds `OPENSSL_ECC_MAX_FIELD_BITS`, this guards against
-CPU exhausition attacks via excessively large inputs.
-
-The above issues do not arise in processing X.509 certificates.  These
-generally have EC keys from "named curves", and RFC5840 (Section 2.1.1)
-disallows explicit EC parameters.  The TLS code in OpenSSL enforces this
-constraint only after the certificate is decoded, but, even if explicit
-parameters are specified, they are in X9.62 form, which cannot represent
-problem values as noted above.
-
-Initially reported as oss-fuzz issue 71623.
-
-A closely related issue was earlier reported in
-<https://github.com/openssl/openssl/issues/19826>.
-
-Severity: Low, CVE-2024-9143
-
-Reviewed-by: Matt Caswell <matt@openssl.org>
-Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
-Reviewed-by: Paul Dale <ppzgs1@gmail.com>
-Reviewed-by: Tomas Mraz <tomas@openssl.org>
-(Merged from https://github.com/openssl/openssl/pull/25639)
-
-(cherry picked from commit 8e008cb8b23ec7dc75c45a66eeed09c815b11cd2)
-
-CVE: CVE-2024-9143
-Upstream-Status: Backport [https://github.com/openssl/openssl/commit/bc7e04d7c8d509fb78fc0e285aa948fb0da04700]
-Signed-off-by: Peter Marko <peter.marko@siemens.com>
----
- crypto/bn/bn_gf2m.c     | 28 +++++++++++++++-------
- test/ec_internal_test.c | 51 +++++++++++++++++++++++++++++++++++++++++
- 2 files changed, 71 insertions(+), 8 deletions(-)
-
-diff --git a/crypto/bn/bn_gf2m.c b/crypto/bn/bn_gf2m.c
-index 444c5ca7a3755..ae7e9d751c29c 100644
---- a/crypto/bn/bn_gf2m.c
-+++ b/crypto/bn/bn_gf2m.c
-@@ -15,6 +15,7 @@
- #include "bn_local.h"
- 
- #ifndef OPENSSL_NO_EC2M
-+# include <openssl/ec.h>
- 
- /*
-  * Maximum number of iterations before BN_GF2m_mod_solve_quad_arr should
-@@ -1130,16 +1131,26 @@ int BN_GF2m_mod_solve_quad(BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
- /*
-  * Convert the bit-string representation of a polynomial ( \sum_{i=0}^n a_i *
-  * x^i) into an array of integers corresponding to the bits with non-zero
-- * coefficient.  Array is terminated with -1. Up to max elements of the array
-- * will be filled.  Return value is total number of array elements that would
-- * be filled if array was large enough.
-+ * coefficient.  The array is intended to be suitable for use with
-+ * `BN_GF2m_mod_arr()`, and so the constant term of the polynomial must not be
-+ * zero.  This translates to a requirement that the input BIGNUM `a` is odd.
-+ *
-+ * Given sufficient room, the array is terminated with -1.  Up to max elements
-+ * of the array will be filled.
-+ *
-+ * The return value is total number of array elements that would be filled if
-+ * array was large enough, including the terminating `-1`.  It is `0` when `a`
-+ * is not odd or the constant term is zero contrary to requirement.
-+ *
-+ * The return value is also `0` when the leading exponent exceeds
-+ * `OPENSSL_ECC_MAX_FIELD_BITS`, this guards against CPU exhaustion attacks,
-  */
- int BN_GF2m_poly2arr(const BIGNUM *a, int p[], int max)
- {
-     int i, j, k = 0;
-     BN_ULONG mask;
- 
--    if (BN_is_zero(a))
-+    if (!BN_is_odd(a))
-         return 0;
- 
-     for (i = a->top - 1; i >= 0; i--) {
-@@ -1157,12 +1168,13 @@ int BN_GF2m_poly2arr(const BIGNUM *a, int p[], int max)
-         }
-     }
- 
--    if (k < max) {
-+    if (k > 0 && p[0] > OPENSSL_ECC_MAX_FIELD_BITS)
-+        return 0;
-+
-+    if (k < max)
-         p[k] = -1;
--        k++;
--    }
- 
--    return k;
-+    return k + 1;
- }
- 
- /*
-diff --git a/test/ec_internal_test.c b/test/ec_internal_test.c
-index 5076f9894d5b8..92904cfc42b20 100644
---- a/test/ec_internal_test.c
-+++ b/test/ec_internal_test.c
-@@ -155,6 +155,56 @@ static int field_tests_ecp_mont(void)
- }
- 
- #ifndef OPENSSL_NO_EC2M
-+/* Test that decoding of invalid GF2m field parameters fails. */
-+static int ec2m_field_sanity(void)
-+{
-+    int ret = 0;
-+    BN_CTX *ctx = BN_CTX_new();
-+    BIGNUM *p, *a, *b;
-+    EC_GROUP *group1 = NULL, *group2 = NULL, *group3 = NULL;
-+
-+    TEST_info("Testing GF2m hardening\n");
-+
-+    BN_CTX_start(ctx);
-+    p = BN_CTX_get(ctx);
-+    a = BN_CTX_get(ctx);
-+    if (!TEST_ptr(b = BN_CTX_get(ctx))
-+        || !TEST_true(BN_one(a))
-+        || !TEST_true(BN_one(b)))
-+        goto out;
-+
-+    /* Even pentanomial value should be rejected */
-+    if (!TEST_true(BN_set_word(p, 0xf2)))
-+        goto out;
-+    if (!TEST_ptr_null(group1 = EC_GROUP_new_curve_GF2m(p, a, b, ctx)))
-+        TEST_error("Zero constant term accepted in GF2m polynomial");
-+
-+    /* Odd hexanomial should also be rejected */
-+    if (!TEST_true(BN_set_word(p, 0xf3)))
-+        goto out;
-+    if (!TEST_ptr_null(group2 = EC_GROUP_new_curve_GF2m(p, a, b, ctx)))
-+        TEST_error("Hexanomial accepted as GF2m polynomial");
-+
-+    /* Excessive polynomial degree should also be rejected */
-+    if (!TEST_true(BN_set_word(p, 0x71))
-+        || !TEST_true(BN_set_bit(p, OPENSSL_ECC_MAX_FIELD_BITS + 1)))
-+        goto out;
-+    if (!TEST_ptr_null(group3 = EC_GROUP_new_curve_GF2m(p, a, b, ctx)))
-+        TEST_error("GF2m polynomial degree > %d accepted",
-+                   OPENSSL_ECC_MAX_FIELD_BITS);
-+
-+    ret = group1 == NULL && group2 == NULL && group3 == NULL;
-+
-+ out:
-+    EC_GROUP_free(group1);
-+    EC_GROUP_free(group2);
-+    EC_GROUP_free(group3);
-+    BN_CTX_end(ctx);
-+    BN_CTX_free(ctx);
-+
-+    return ret;
-+}
-+
- /* test EC_GF2m_simple_method directly */
- static int field_tests_ec2_simple(void)
- {
-@@ -443,6 +493,7 @@ int setup_tests(void)
-     ADD_TEST(field_tests_ecp_simple);
-     ADD_TEST(field_tests_ecp_mont);
- #ifndef OPENSSL_NO_EC2M
-+    ADD_TEST(ec2m_field_sanity);
-     ADD_TEST(field_tests_ec2_simple);
- #endif
-     ADD_ALL_TESTS(field_tests_default, crv_len);

meta/recipes-connectivity/openssl/openssl_3.2.4.bb

@@ -12,14 +12,13 @@ SRC_URI = "https://github.com/openssl/openssl/releases/download/openssl-${PV}/op
            file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
            file://0001-Configure-do-not-tweak-mips-cflags.patch \
            file://0001-Added-handshake-history-reporting-when-test-fails.patch \
-           file://CVE-2024-9143.patch \
            "
 
 SRC_URI:append:class-nativesdk = " \
            file://environment.d-openssl.sh \
            "
 
-SRC_URI[sha256sum] = "52b5f1c6b8022bc5868c308c54fb77705e702d6c6f4594f99a0df216acf46239"
+SRC_URI[sha256sum] = "b23ad7fd9f73e43ad1767e636040e88ba7c9e5775bfa5618436a0dd2c17c3716"
 
 inherit lib_package multilib_header multilib_script ptest perlnative manpages
 MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"

meta/recipes-connectivity/ppp/ppp/0001-Revert-lock-path-to-var-lock-435.patch

@@ -0,0 +1,63 @@
+From 99cbf5e269994482edaf64624be8b1c806f9587c Mon Sep 17 00:00:00 2001
+From: Dominique Martinet <asmadeus@codewreck.org>
+Date: Tue, 10 Oct 2023 10:05:50 +0900
+Subject: [PATCH] Revert lock path to /var/lock (#435)
+
+lock dir changed on linux from /var/lock to /run/pppd/lock with
+pppd-2.5.0, which makes pppd fail to start if the distribution does not
+pre-create the directory.
+
+This reverts it back to /var/lock.
+
+The paths for other OS should be identical as LOCALSTATEDIR should be
+/var, but also revert them back as well just in case.
+Since the variable is no longer used remove it from makefiles.
+
+Fixes: 66a8c74c3f73 ("Let ./configure control the paths for pppd")
+Fixes: #419
+
+Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
+Co-authored-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
+
+Upstream-Status: Backport [https://github.com/ppp-project/ppp/commit/99cbf5e269994482edaf64624be8b1c806f9587c]
+---
+ pppd/Makefile.am | 2 +-
+ pppd/pathnames.h | 6 +++---
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/pppd/Makefile.am b/pppd/Makefile.am
+index e5bedf2..7cb3005 100644
+--- a/pppd/Makefile.am
++++ b/pppd/Makefile.am
+@@ -83,7 +83,7 @@ pppd_SOURCES = \
+     upap.c \
+     utils.c
+ 
+-pppd_CPPFLAGS = -DSYSCONFDIR=\"${sysconfdir}\" -DLOCALSTATEDIR=\"${localstatedir}\" -DPPPD_RUNTIME_DIR='"@PPPD_RUNTIME_DIR@"' -DPPPD_LOGFILE_DIR='"@PPPD_LOGFILE_DIR@"'
++pppd_CPPFLAGS = -DSYSCONFDIR=\"${sysconfdir}\" -DPPPD_RUNTIME_DIR='"@PPPD_RUNTIME_DIR@"' -DPPPD_LOGFILE_DIR='"@PPPD_LOGFILE_DIR@"'
+ pppd_LDFLAGS =
+ pppd_LIBS =
+ 
+diff --git a/pppd/pathnames.h b/pppd/pathnames.h
+index de2fb68..12609a9 100644
+--- a/pppd/pathnames.h
++++ b/pppd/pathnames.h
+@@ -120,12 +120,12 @@
+ #define PPP_PATH_PPPDB          PPP_PATH_VARRUN  "/pppd2.tdb"
+ 
+ #ifdef __linux__
+-#define PPP_PATH_LOCKDIR        PPP_PATH_VARRUN  "/lock"
++#define PPP_PATH_LOCKDIR        "/var/lock"
+ #else
+ #ifdef SVR4
+-#define PPP_PATH_LOCKDIR        LOCALSTATEDIR "/spool/locks"
++#define PPP_PATH_LOCKDIR        "/var/spool/locks"
+ #else
+-#define PPP_PATH_LOCKDIR        LOCALSTATEDIR "/spool/lock"
++#define PPP_PATH_LOCKDIR        "/var/spool/lock"
+ #endif
+ #endif
+ 
+-- 
+2.43.0
+

meta/recipes-connectivity/ppp/ppp_2.5.0.bb

@@ -23,6 +23,7 @@ SRC_URI = "https://download.samba.org/pub/${BPN}/${BP}.tar.gz \
            file://ppp_on_boot \
            file://provider \
            file://ppp@.service \
+           file://0001-Revert-lock-path-to-var-lock-435.patch \
            "
 
 SRC_URI[sha256sum] = "5cae0e8075f8a1755f16ca290eb44e6b3545d3f292af4da65ecffe897de636ff"

meta/recipes-core/base-files/base-files_3.0.14.bb

@@ -70,29 +70,6 @@ hostname = "${MACHINE}"
 
 BASEFILESISSUEINSTALL ?= "do_install_basefilesissue"
 
-# In previous versions of base-files, /run was a softlink to /var/run and the
-# directory was located in /var/volatlie/run.  Also, /var/lock was a softlink
-# to /var/volatile/lock which is where the real directory was located.  Now,
-# /run and /run/lock are the real directories.  If we are upgrading, we may
-# need to remove the symbolic links first before we create the directories.
-# Otherwise the directory creation will fail and we will have circular symbolic
-# links.
-# 
-pkg_preinst:${PN} () {
-    #!/bin/sh -e
-    if [ x"$D" = "x" ]; then
-        if [ -h "/var/lock" ]; then
-            # Remove the symbolic link
-            rm -f /var/lock
-        fi
-
-        if [ -h "/run" ]; then
-            # Remove the symbolic link
-            rm -f /run
-        fi
-    fi     
-}
-
 do_install () {
 	for d in ${dirs555}; do
 		install -m 0555 -d ${D}$d

meta/recipes-core/glibc/glibc-version.inc

@@ -1,6 +1,6 @@
 SRCBRANCH ?= "release/2.39/master"
 PV = "2.39+git"
-SRCREV_glibc ?= "dcaf51b41e259387602774829c45222d0507f90a"
+SRCREV_glibc ?= "662516aca8b6bf6aa6555f471055d5eb512b1ddc"
 SRCREV_localedef ?= "fab74f31b3811df543e24b6de47efdf45b538abc"
 
 GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https"

meta/recipes-core/glibc/glibc_2.39.bb

@@ -17,7 +17,7 @@ Allows for ASLR bypass so can bypass some hardening, not an exploit in itself, m
 easier access for another. 'ASLR bypass itself is not a vulnerability.'"
 
 CVE_STATUS_GROUPS += "CVE_STATUS_STABLE_BACKPORTS"
-CVE_STATUS_STABLE_BACKPORTS = "CVE-2024-2961 CVE-2024-33599 CVE-2024-33600 CVE-2024-33601 CVE-2024-33602"
+CVE_STATUS_STABLE_BACKPORTS = "CVE-2024-2961 CVE-2024-33599 CVE-2024-33600 CVE-2024-33601 CVE-2024-33602 CVE-2025-0395"
 CVE_STATUS_STABLE_BACKPORTS[status] = "cpe-stable-backport: fix available in used git hash"
 
 DEPENDS += "gperf-native bison-native"

meta/recipes-core/images/build-appliance-image_15.0.0.bb

@@ -26,7 +26,7 @@ inherit core-image setuptools3 features_check
 
 REQUIRED_DISTRO_FEATURES += "xattr"
 
-SRCREV ?= "dd941e5746af70d71a5c0ebef49c1f4108168964"
+SRCREV ?= "dc4fe2810d79cb0a6dd7ffd3b728307960bfb1a2"
 SRC_URI = "git://git.yoctoproject.org/poky;branch=scarthgap \
            file://Yocto_Build_Appliance.vmx \
            file://Yocto_Build_Appliance.vmxf \

meta/recipes-core/libxml/libxml2_2.12.10.bb

@@ -20,7 +20,7 @@ SRC_URI += "http://www.w3.org/XML/Test/xmlts20130923.tar;subdir=${BP};name=testt
            file://install-tests.patch \
            "
 
-SRC_URI[archive.sha256sum] = "59912db536ab56a3996489ea0299768c7bcffe57169f0235e7f962a91f483590"
+SRC_URI[archive.sha256sum] = "c3d8c0c34aa39098f66576fe51969db12a5100b956233dc56506f7a8679be995"
 SRC_URI[testtar.sha256sum] = "c6b2d42ee50b8b236e711a97d68e6c4b5c8d83e69a2be4722379f08702ea7273"
 
 # Disputed as a security issue, but fixed in d39f780

meta/recipes-core/systemd/systemd.inc

@@ -15,7 +15,7 @@ LICENSE:libsystemd = "LGPL-2.1-or-later"
 LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
                     file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c"
 
-SRCREV = "565916c245b53b49f5917f5326d21246f46ae3db"
+SRCREV = "fb92304041cd203d2ca84cc28721dea5e1355c4e"
 SRCBRANCH = "v255-stable"
 SRC_URI = "git://github.com/systemd/systemd-stable.git;protocol=https;branch=${SRCBRANCH}"
 

meta/recipes-core/systemd/systemd/0001-missing_type.h-add-comparison_fn_t.patch

@@ -1,4 +1,4 @@
-From af2784935b483bd0eb5705ef7072a5cea6fe9eef Mon Sep 17 00:00:00 2001
+From abbda6d89c0b850c0adeebc3e210d9b255072a40 Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Mon, 25 Feb 2019 13:55:12 +0800
 Subject: [PATCH] missing_type.h: add comparison_fn_t

meta/recipes-core/systemd/systemd/0002-add-fallback-parse_printf_format-implementation.patch

@@ -1,4 +1,4 @@
-From b9b4f9bbca46832ea152979d8c9459f29c2e83fa Mon Sep 17 00:00:00 2001
+From adaa70c17daedd8d81525d080fda8a1e22efe3a4 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Sat, 22 May 2021 20:26:24 +0200
 Subject: [PATCH] add fallback parse_printf_format implementation
@@ -22,10 +22,10 @@ Signed-off-by: Scott Murray <scott.murray@konsulko.com>
  create mode 100644 src/basic/parse-printf-format.h
 
 diff --git a/meson.build b/meson.build
-index 2418d6e8f7..b544a69aaa 100644
+index d5109b0d00..ccde927cf3 100644
 --- a/meson.build
 +++ b/meson.build
-@@ -731,6 +731,7 @@ endif
+@@ -732,6 +732,7 @@ endif
  foreach header : ['crypt.h',
                    'linux/memfd.h',
                    'linux/vm_sockets.h',

meta/recipes-core/systemd/systemd/0002-binfmt-Don-t-install-dependency-links-at-install-tim.patch

@@ -1,4 +1,4 @@
-From 178b7b4adefdf1d80fa3a5eb54a49ef0fc12369f Mon Sep 17 00:00:00 2001
+From 95bf78fe7d7b7d41ff43e761bb78adfb4fdb9303 Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Thu, 21 Feb 2019 16:23:24 +0800
 Subject: [PATCH] binfmt: Don't install dependency links at install time for

meta/recipes-core/systemd/systemd/0003-src-basic-missing.h-check-for-missing-strndupa.patch

@@ -1,7 +1,10 @@
-From eca6019bbd793c8d8a99142677a548766a775153 Mon Sep 17 00:00:00 2001
+From 76f4749e3a583ad3c924bdff4a6bde967c674ed7 Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Mon, 25 Feb 2019 14:18:21 +0800
 Subject: [PATCH] src/basic/missing.h: check for missing strndupa
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
 
 include missing.h  for definition of strndupa
 
@@ -20,6 +23,8 @@ Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
 [Rebased for v254]
 Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
 [Rebased for v255.1]
+Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com>
+[Rebased for v255.14]
 ---
  meson.build                                |  1 +
  src/backlight/backlight.c                  |  1 +
@@ -75,7 +80,7 @@ Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
  51 files changed, 62 insertions(+)
 
 diff --git a/meson.build b/meson.build
-index b544a69aaa..90b07aeb14 100644
+index 216a8cbc91..d5109b0d00 100644
 --- a/meson.build
 +++ b/meson.build
 @@ -572,6 +572,7 @@ foreach ident : ['secure_getenv', '__secure_getenv']
@@ -99,7 +104,7 @@ index b2032adaa5..ee9201826d 100644
  #define PCI_CLASS_GRAPHICS_CARD 0x30000
  
 diff --git a/src/basic/cgroup-util.c b/src/basic/cgroup-util.c
-index 50224648d3..2eaa6e3307 100644
+index e978bd3eff..d08c903c3b 100644
 --- a/src/basic/cgroup-util.c
 +++ b/src/basic/cgroup-util.c
 @@ -38,6 +38,7 @@
@@ -239,7 +244,7 @@ index d7cfcd9105..6cb0ddf575 100644
  int procfs_get_pid_max(uint64_t *ret) {
          _cleanup_free_ char *value = NULL;
 diff --git a/src/basic/time-util.c b/src/basic/time-util.c
-index f9014dc560..1d7840a5b5 100644
+index 0c2d739977..5c150806a0 100644
 --- a/src/basic/time-util.c
 +++ b/src/basic/time-util.c
 @@ -27,6 +27,7 @@
@@ -263,7 +268,7 @@ index 12dfdf76fa..e66332519a 100644
  static char **arg_path = NULL;
  
 diff --git a/src/core/dbus-cgroup.c b/src/core/dbus-cgroup.c
-index 88198010ee..74d61bfaaf 100644
+index b3baf03afc..7404784a01 100644
 --- a/src/core/dbus-cgroup.c
 +++ b/src/core/dbus-cgroup.c
 @@ -25,6 +25,7 @@
@@ -299,7 +304,7 @@ index 7bb026af48..a86128e40c 100644
  int bus_property_get_triggered_unit(
                  sd_bus *bus,
 diff --git a/src/core/execute.c b/src/core/execute.c
-index 4d597bf8a6..7d27f80834 100644
+index aa179fd57e..1ee9f4526b 100644
 --- a/src/core/execute.c
 +++ b/src/core/execute.c
 @@ -72,6 +72,7 @@
@@ -323,7 +328,7 @@ index b8e3f7aadd..8ce8ca68d8 100644
  #if HAVE_KMOD
  #include "module-util.h"
 diff --git a/src/core/service.c b/src/core/service.c
-index 5f4859e0d3..a920154f55 100644
+index d3ea8a9c3c..c3441f785c 100644
 --- a/src/core/service.c
 +++ b/src/core/service.c
 @@ -45,6 +45,7 @@
@@ -371,7 +376,7 @@ index 2d380bc7a7..d3f5612728 100644
  #define PRIV_KEY_FILE CERTIFICATE_ROOT "/private/journal-remote.pem"
  #define CERT_FILE     CERTIFICATE_ROOT "/certs/journal-remote.pem"
 diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
-index 87e2f28841..58275f41f1 100644
+index f52ed03dd0..3fa708a906 100644
 --- a/src/journal/journalctl.c
 +++ b/src/journal/journalctl.c
 @@ -77,6 +77,7 @@
@@ -443,7 +448,7 @@ index d988588de0..458df8df9a 100644
  #define MAX_SIZE (2*1024*1024)
  
 diff --git a/src/libsystemd/sd-journal/sd-journal.c b/src/libsystemd/sd-journal/sd-journal.c
-index 7a1dd2569f..d187baad47 100644
+index acabec699f..8115d3784a 100644
 --- a/src/libsystemd/sd-journal/sd-journal.c
 +++ b/src/libsystemd/sd-journal/sd-journal.c
 @@ -44,6 +44,7 @@
@@ -467,19 +472,19 @@ index bf45974ca5..2cb7e930c0 100644
  #include "parse-util.h"
  #include "path-util.h"
 diff --git a/src/network/generator/network-generator.c b/src/network/generator/network-generator.c
-index 48527a2c73..9777fe0561 100644
+index e5f78a3b99..4833de2009 100644
 --- a/src/network/generator/network-generator.c
 +++ b/src/network/generator/network-generator.c
-@@ -14,6 +14,7 @@
- #include "string-table.h"
+@@ -15,6 +15,7 @@
  #include "string-util.h"
  #include "strv.h"
+ #include "vlan-util.h"
 +#include "missing_stdlib.h"
  
  /*
    # .network
 diff --git a/src/nspawn/nspawn-settings.c b/src/nspawn/nspawn-settings.c
-index 161b1c1c70..ba1c459f78 100644
+index 2bb034eb22..c9837b8d79 100644
 --- a/src/nspawn/nspawn-settings.c
 +++ b/src/nspawn/nspawn-settings.c
 @@ -16,6 +16,7 @@
@@ -503,7 +508,7 @@ index c64e79bdff..eda26b0b9a 100644
  static void setup_logging_once(void) {
          static pthread_once_t once = PTHREAD_ONCE_INIT;
 diff --git a/src/portable/portable.c b/src/portable/portable.c
-index faeb97bd06..30768f728e 100644
+index 4aced8c391..6f426e0e51 100644
 --- a/src/portable/portable.c
 +++ b/src/portable/portable.c
 @@ -42,6 +42,7 @@

meta/recipes-core/systemd/systemd/0004-don-t-fail-if-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch

@@ -1,4 +1,4 @@
-From a15045a60893f29ce9720e62cafbc0b87908ad49 Mon Sep 17 00:00:00 2001
+From e9110b095a5728762b3bd3abdec2a99b4ce01b5e Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Mon, 25 Feb 2019 14:56:21 +0800
 Subject: [PATCH] don't fail if GLOB_BRACE and GLOB_ALTDIRFUNC is not defined

meta/recipes-core/systemd/systemd/0005-add-missing-FTW_-macros-for-musl.patch

@@ -1,4 +1,4 @@
-From b2c98ef636ac7dfdf86e7a42aebc3142a5b167d2 Mon Sep 17 00:00:00 2001
+From 1eeac3e8ce96ad5da381555e93a57330cb8a5d48 Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Mon, 25 Feb 2019 15:00:06 +0800
 Subject: [PATCH] add missing FTW_ macros for musl

meta/recipes-core/systemd/systemd/0006-Use-uintmax_t-for-handling-rlim_t.patch

@@ -1,4 +1,4 @@
-From 3ea46787827fb6db631b240589d2f447b977f7d9 Mon Sep 17 00:00:00 2001
+From fd2bb25921040fc5faed3a4aae0bd9e03f8f4742 Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Mon, 25 Feb 2019 15:12:41 +0800
 Subject: [PATCH] Use uintmax_t for handling rlim_t
@@ -86,10 +86,10 @@ index c1f0b2b974..61c5412582 100644
          return 1;
  }
 diff --git a/src/core/execute.c b/src/core/execute.c
-index 7d27f80834..bde0f8137c 100644
+index 1ee9f4526b..cb29799afb 100644
 --- a/src/core/execute.c
 +++ b/src/core/execute.c
-@@ -1042,9 +1042,9 @@ void exec_context_dump(const ExecContext *c, FILE* f, const char *prefix) {
+@@ -1043,9 +1043,9 @@ void exec_context_dump(const ExecContext *c, FILE* f, const char *prefix) {
          for (unsigned i = 0; i < RLIM_NLIMITS; i++)
                  if (c->rlimit[i]) {
                          fprintf(f, "%sLimit%s: " RLIM_FMT "\n",

meta/recipes-core/systemd/systemd/0007-don-t-pass-AT_SYMLINK_NOFOLLOW-flag-to-faccessat.patch

@@ -1,4 +1,4 @@
-From 0e51be93aa8c647bf1761d684c722b92d3cfabc1 Mon Sep 17 00:00:00 2001
+From fde97394bf1a2faffa420afb098af61676033640 Mon Sep 17 00:00:00 2001
 From: Andre McCurdy <armccurdy@gmail.com>
 Date: Tue, 10 Oct 2017 14:33:30 -0700
 Subject: [PATCH] don't pass AT_SYMLINK_NOFOLLOW flag to faccessat()

meta/recipes-core/systemd/systemd/0008-Define-glibc-compatible-basename-for-non-glibc-syste.patch

@@ -1,4 +1,4 @@
-From 9f85e2db2b40313de555b3103aa485b9b84382fe Mon Sep 17 00:00:00 2001
+From e2e1fee9fd5635420408777524dd418ce10dddc8 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Sun, 27 May 2018 08:36:44 -0700
 Subject: [PATCH] Define glibc compatible basename() for non-glibc systems

meta/recipes-core/systemd/systemd/0008-implment-systemd-sysv-install-for-OE.patch

@@ -1,4 +1,4 @@
-From c223945b20aadd1e3b1f3986e159cb3755aabf99 Mon Sep 17 00:00:00 2001
+From 2b40558d201b73962077d0cedef820dfe95395c7 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Sat, 5 Sep 2015 06:31:47 +0000
 Subject: [PATCH] implment systemd-sysv-install for OE

meta/recipes-core/systemd/systemd/0009-Do-not-disable-buffering-when-writing-to-oom_score_a.patch

@@ -1,4 +1,4 @@
-From 64b98f7ba1f5211bd19cd98c9d7e4d0f884cf65d Mon Sep 17 00:00:00 2001
+From b783adf25c5619931189b4474d389a808e7845d6 Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Wed, 4 Jul 2018 15:00:44 +0800
 Subject: [PATCH] Do not disable buffering when writing to oom_score_adj
@@ -24,7 +24,7 @@ Signed-off-by: Scott Murray <scott.murray@konsulko.com>
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/basic/process-util.c b/src/basic/process-util.c
-index 4492e7ded2..b61a2aba74 100644
+index 1447f65399..dcbc7ac973 100644
 --- a/src/basic/process-util.c
 +++ b/src/basic/process-util.c
 @@ -1716,7 +1716,7 @@ int set_oom_score_adjust(int value) {

meta/recipes-core/systemd/systemd/0010-distinguish-XSI-compliant-strerror_r-from-GNU-specif.patch

@@ -1,4 +1,4 @@
-From bc75e47baaddbd629d9757a2539102649d9501fd Mon Sep 17 00:00:00 2001
+From ac820a745c905e0045ce5cc41da7eaa802078b1b Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Tue, 10 Jul 2018 15:40:17 +0800
 Subject: [PATCH] distinguish XSI-compliant strerror_r from GNU-specifi

meta/recipes-core/systemd/systemd/0011-avoid-redefinition-of-prctl_mm_map-structure.patch

@@ -1,4 +1,4 @@
-From e8a03df3275aef82a1bfd5c1ce60058c5e39eb09 Mon Sep 17 00:00:00 2001
+From 4a2472cae75720b3129260c8789a87af26ca443a Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Mon, 25 Feb 2019 15:44:54 +0800
 Subject: [PATCH] avoid redefinition of prctl_mm_map structure

meta/recipes-core/systemd/systemd/0012-do-not-disable-buffer-in-writing-files.patch

@@ -1,4 +1,4 @@
-From f3630404d25dd91e87e7aac09d5dee9b92655082 Mon Sep 17 00:00:00 2001
+From 8072fee9fcb0e9a8c73de56f38468e7287ac4961 Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Fri, 1 Mar 2019 15:22:15 +0800
 Subject: [PATCH] do not disable buffer in writing files
@@ -47,7 +47,7 @@ Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
  22 files changed, 50 insertions(+), 51 deletions(-)
 
 diff --git a/src/basic/cgroup-util.c b/src/basic/cgroup-util.c
-index 2eaa6e3307..5c2876b5c9 100644
+index d08c903c3b..77ebe85dfd 100644
 --- a/src/basic/cgroup-util.c
 +++ b/src/basic/cgroup-util.c
 @@ -443,7 +443,7 @@ int cg_kill_kernel_sigkill(const char *path) {
@@ -59,7 +59,7 @@ index 2eaa6e3307..5c2876b5c9 100644
          if (r < 0)
                  return r;
  
-@@ -869,7 +869,7 @@ int cg_install_release_agent(const char *controller, const char *agent) {
+@@ -873,7 +873,7 @@ int cg_install_release_agent(const char *controller, const char *agent) {
  
          sc = strstrip(contents);
          if (isempty(sc)) {
@@ -68,7 +68,7 @@ index 2eaa6e3307..5c2876b5c9 100644
                  if (r < 0)
                          return r;
          } else if (!path_equal(sc, agent))
-@@ -887,7 +887,7 @@ int cg_install_release_agent(const char *controller, const char *agent) {
+@@ -891,7 +891,7 @@ int cg_install_release_agent(const char *controller, const char *agent) {
  
          sc = strstrip(contents);
          if (streq(sc, "0")) {
@@ -77,7 +77,7 @@ index 2eaa6e3307..5c2876b5c9 100644
                  if (r < 0)
                          return r;
  
-@@ -914,7 +914,7 @@ int cg_uninstall_release_agent(const char *controller) {
+@@ -918,7 +918,7 @@ int cg_uninstall_release_agent(const char *controller) {
          if (r < 0)
                  return r;
  
@@ -86,7 +86,7 @@ index 2eaa6e3307..5c2876b5c9 100644
          if (r < 0)
                  return r;
  
-@@ -924,7 +924,7 @@ int cg_uninstall_release_agent(const char *controller) {
+@@ -928,7 +928,7 @@ int cg_uninstall_release_agent(const char *controller) {
          if (r < 0)
                  return r;
  
@@ -95,7 +95,7 @@ index 2eaa6e3307..5c2876b5c9 100644
          if (r < 0)
                  return r;
  
-@@ -1840,7 +1840,7 @@ int cg_set_attribute(const char *controller, const char *path, const char *attri
+@@ -1844,7 +1844,7 @@ int cg_set_attribute(const char *controller, const char *path, const char *attri
          if (r < 0)
                  return r;
  
@@ -201,10 +201,10 @@ index 61539afdbf..77e2b35daf 100644
                  return r;
  
 diff --git a/src/core/main.c b/src/core/main.c
-index 1c0030a75f..7108a87d46 100644
+index 8373a156cb..33e866942c 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
-@@ -1678,7 +1678,7 @@ static void initialize_core_pattern(bool skip_setup) {
+@@ -1683,7 +1683,7 @@ static void initialize_core_pattern(bool skip_setup) {
          if (getpid_cached() != 1)
                  return;
  
@@ -253,7 +253,7 @@ index 500c310cfc..f9845ff9e7 100644
                  log_warning_errno(r, "Failed to drop caches, ignoring: %m");
          else
 diff --git a/src/libsystemd/sd-device/sd-device.c b/src/libsystemd/sd-device/sd-device.c
-index 01e66b4658..f3ea82ca1b 100644
+index 5f7491e8e2..b4a0af4073 100644
 --- a/src/libsystemd/sd-device/sd-device.c
 +++ b/src/libsystemd/sd-device/sd-device.c
 @@ -2516,7 +2516,7 @@ _public_ int sd_device_set_sysattr_value(sd_device *device, const char *sysattr,
@@ -279,10 +279,10 @@ index a5002437c6..b12e6cd9c9 100644
                  log_error_errno(r, "Failed to move process: %m");
                  goto finish;
 diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
-index a229c70875..4ceb73e915 100644
+index 005a3d2be1..526d3c4311 100644
 --- a/src/nspawn/nspawn.c
 +++ b/src/nspawn/nspawn.c
-@@ -2690,7 +2690,7 @@ static int reset_audit_loginuid(void) {
+@@ -2707,7 +2707,7 @@ static int reset_audit_loginuid(void) {
          if (streq(p, "4294967295"))
                  return 0;
  
@@ -291,7 +291,7 @@ index a229c70875..4ceb73e915 100644
          if (r < 0) {
                  log_error_errno(r,
                                  "Failed to reset audit login UID. This probably means that your kernel is too\n"
-@@ -4143,7 +4143,7 @@ static int setup_uid_map(
+@@ -4160,7 +4160,7 @@ static int setup_uid_map(
                  return log_oom();
  
          xsprintf(uid_map, "/proc/" PID_FMT "/uid_map", pid);
@@ -300,7 +300,7 @@ index a229c70875..4ceb73e915 100644
          if (r < 0)
                  return log_error_errno(r, "Failed to write UID map: %m");
  
-@@ -4153,7 +4153,7 @@ static int setup_uid_map(
+@@ -4170,7 +4170,7 @@ static int setup_uid_map(
                  return log_oom();
  
          xsprintf(uid_map, "/proc/" PID_FMT "/gid_map", pid);
@@ -367,10 +367,10 @@ index 805503f366..01a7ccb291 100644
                  log_debug_errno(r, "Failed to turn off coredumps, ignoring: %m");
  }
 diff --git a/src/shared/hibernate-util.c b/src/shared/hibernate-util.c
-index ea1b024ab6..bb82f37580 100644
+index 67862dcc61..9e9265c214 100644
 --- a/src/shared/hibernate-util.c
 +++ b/src/shared/hibernate-util.c
-@@ -501,7 +501,7 @@ int write_resume_config(dev_t devno, uint64_t offset, const char *device) {
+@@ -504,7 +504,7 @@ int write_resume_config(dev_t devno, uint64_t offset, const char *device) {
  
          /* We write the offset first since it's safer. Note that this file is only available in 4.17+, so
           * fail gracefully if it doesn't exist and we're only overwriting it with 0. */
@@ -379,7 +379,7 @@ index ea1b024ab6..bb82f37580 100644
          if (r == -ENOENT) {
                  if (offset != 0)
                          return log_error_errno(SYNTHETIC_ERRNO(EOPNOTSUPP),
-@@ -517,7 +517,7 @@ int write_resume_config(dev_t devno, uint64_t offset, const char *device) {
+@@ -520,7 +520,7 @@ int write_resume_config(dev_t devno, uint64_t offset, const char *device) {
                  log_debug("Wrote resume_offset=%s for device '%s' to /sys/power/resume_offset.",
                            offset_str, device);
  

meta/recipes-core/systemd/systemd/0013-Handle-__cpu_mask-usage.patch

@@ -1,4 +1,4 @@
-From db390dc6bfa0a7b27010e0dcd25f45f17a6e3954 Mon Sep 17 00:00:00 2001
+From 4b46cf08f269b69d5336bf3d8f617a288bd65ea8 Mon Sep 17 00:00:00 2001
 From: Scott Murray <scott.murray@konsulko.com>
 Date: Fri, 13 Sep 2019 19:26:27 -0400
 Subject: [PATCH] Handle __cpu_mask usage

meta/recipes-core/systemd/systemd/0014-Handle-missing-gshadow.patch

@@ -1,4 +1,4 @@
-From 0019ddcc5c415df52504dd2b779b5acb19e4084d Mon Sep 17 00:00:00 2001
+From 76a0eea205c943a0e1fd0db7336cabb98d5c6c8c Mon Sep 17 00:00:00 2001
 From: Alex Kiernan <alex.kiernan@gmail.com>
 Date: Tue, 10 Mar 2020 11:05:20 +0000
 Subject: [PATCH] Handle missing gshadow

meta/recipes-core/systemd/systemd/0015-missing_syscall.h-Define-MIPS-ABI-defines-for-musl.patch

@@ -1,4 +1,4 @@
-From eb4095a963a51a1b3de693f8cf0ac27304f30d24 Mon Sep 17 00:00:00 2001
+From bd309e23e3e5b7bff8cd4b6778396d921438295e Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Mon, 12 Apr 2021 23:44:53 -0700
 Subject: [PATCH] missing_syscall.h: Define MIPS ABI defines for musl

meta/recipes-core/systemd/systemd/0016-pass-correct-parameters-to-getdents64.patch

@@ -1,4 +1,4 @@
-From c9c0cdbc37c2e0ac1917188b6f3a1ad54cbbd816 Mon Sep 17 00:00:00 2001
+From 81eb93545808124b3c1abbef2e5d71ad28a1a870 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Fri, 21 Jan 2022 15:15:11 -0800
 Subject: [PATCH] pass correct parameters to getdents64

meta/recipes-core/systemd/systemd/0017-Adjust-for-musl-headers.patch

@@ -1,4 +1,4 @@
-From 038809fb270d11909d502d76b56bb83784ff478d Mon Sep 17 00:00:00 2001
+From d09615e61bc779228c996f024ec48c7e21eb64c9 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Fri, 21 Jan 2022 22:19:37 -0800
 Subject: [PATCH] Adjust for musl headers
@@ -242,7 +242,7 @@ index ff372092e6..eef66811f4 100644
  #include "nlmon.h"
  
 diff --git a/src/network/netdev/tunnel.c b/src/network/netdev/tunnel.c
-index db84e7cf6e..93d5642962 100644
+index ab3b8fbb51..68f88b3ca3 100644
 --- a/src/network/netdev/tunnel.c
 +++ b/src/network/netdev/tunnel.c
 @@ -2,7 +2,7 @@
@@ -332,7 +332,7 @@ index b11fdbbd0d..a971a917f0 100644
  #include "conf-parser.h"
  #include "alloc-util.h"
 diff --git a/src/network/netdev/wireguard.c b/src/network/netdev/wireguard.c
-index 4c7d837c41..6df6dfb816 100644
+index 52fed20b57..e66bc34993 100644
 --- a/src/network/netdev/wireguard.c
 +++ b/src/network/netdev/wireguard.c
 @@ -6,7 +6,7 @@

meta/recipes-core/systemd/systemd/0018-test-bus-error-strerror-is-assumed-to-be-GNU-specifi.patch

@@ -1,4 +1,4 @@
-From b771a2ed8d6e07b006710767b79475dece4d789c Mon Sep 17 00:00:00 2001
+From c0c90f4e2381091830203e1286115b0a30e059d3 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Tue, 8 Nov 2022 13:31:34 -0800
 Subject: [PATCH] test-bus-error: strerror() is assumed to be GNU specific

meta/recipes-core/systemd/systemd/0019-errno-util-Make-STRERROR-portable-for-musl.patch

@@ -1,4 +1,4 @@
-From f70a8031ded3bcfe4c5f1cea4763ae257ca27be8 Mon Sep 17 00:00:00 2001
+From 6ad0fb9dcd6940a9a24e515b61d4b6245c3b1e98 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Mon, 23 Jan 2023 23:39:46 -0800
 Subject: [PATCH] errno-util: Make STRERROR portable for musl

meta/recipes-core/systemd/systemd/0020-sd-event-Make-malloc_trim-conditional-on-glibc.patch

@@ -1,4 +1,4 @@
-From 9ae5377acfa895bfc1ea61aef4fbe754bc2f7f33 Mon Sep 17 00:00:00 2001
+From 70abcbd93b8854c4dd0ae88b82f394d325b2a365 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Wed, 2 Aug 2023 12:06:27 -0700
 Subject: [PATCH] sd-event: Make malloc_trim() conditional on glibc
@@ -12,7 +12,7 @@ Signed-off-by: Khem Raj <raj.khem@gmail.com>
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/libsystemd/sd-event/sd-event.c b/src/libsystemd/sd-event/sd-event.c
-index 25f3b1fc4f..9ea3c964b2 100644
+index b3541a1429..ba87265d9f 100644
 --- a/src/libsystemd/sd-event/sd-event.c
 +++ b/src/libsystemd/sd-event/sd-event.c
 @@ -1874,7 +1874,7 @@ _public_ int sd_event_add_exit(

meta/recipes-core/systemd/systemd/0021-shared-Do-not-use-malloc_info-on-musl.patch

@@ -1,4 +1,4 @@
-From d814a5cae2ecbee079816e3fc7b34a59da356a3b Mon Sep 17 00:00:00 2001
+From c85009340b3a58686390ee70671334593e348a10 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Wed, 2 Aug 2023 12:20:40 -0700
 Subject: [PATCH] shared: Do not use malloc_info on musl

meta/recipes-core/systemd/systemd/0022-avoid-missing-LOCK_EX-declaration.patch

@@ -1,4 +1,4 @@
-From e355e927950e8978a417067f25f30bf311896c96 Mon Sep 17 00:00:00 2001
+From 45478696b3a3eb1fbcd6c5cd4899bb426230c2e1 Mon Sep 17 00:00:00 2001
 From: Chen Qi <Qi.Chen@windriver.com>
 Date: Tue, 2 Jan 2024 11:03:27 +0800
 Subject: [PATCH] avoid missing LOCK_EX declaration
@@ -15,7 +15,7 @@ Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
  2 files changed, 2 insertions(+)
 
 diff --git a/src/core/exec-invoke.c b/src/core/exec-invoke.c
-index 308d332c15..b1c43bbc6a 100644
+index 22bc8d10c1..9bced8f420 100644
 --- a/src/core/exec-invoke.c
 +++ b/src/core/exec-invoke.c
 @@ -5,6 +5,7 @@

meta/recipes-core/systemd/systemd_255.17.bb

@@ -188,7 +188,7 @@ PACKAGECONFIG[oomd] = "-Doomd=true,-Doomd=false"
 PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
 PACKAGECONFIG[p11kit] = "-Dp11kit=true,-Dp11kit=false,p11-kit"
 PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
-PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=false,libpcre2"
+PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=false,libpcre2,,libpcre2"
 PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
 # If polkit is disabled and networkd+hostnamed are in use, enabling this option and
 # using dbus-broker will allow networkd to be authorized to change the

meta/recipes-devtools/binutils/binutils-2.42.inc

@@ -20,7 +20,7 @@ UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P<pver>\d+_(\d_?)*)"
 
 CVE_STATUS[CVE-2023-25584] = "cpe-incorrect: Applies only for version 2.40 and earlier"
 
-SRCREV ?= "09ba78f051319e8f8861b26fb9340e21ca973c70"
+SRCREV ?= "758a2290dbdf0d6d6c148c6cf25b2bcfd7a5b84f"
 BINUTILS_GIT_URI ?= "git://sourceware.org/git/binutils-gdb.git;branch=${SRCBRANCH};protocol=https"
 SRC_URI = "\
      ${BINUTILS_GIT_URI} \
@@ -37,5 +37,7 @@ SRC_URI = "\
      file://0014-Remove-duplicate-pe-dll.o-entry-deom-targ_extra_ofil.patch \
      file://0015-gprofng-change-use-of-bignum-to-bigint.patch \
      file://0016-CVE-2024-53589.patch \
+     file://0017-dlltool-file-name-too-long.patch \
+     file://0018-CVE-2025-0840.patch \
 "
 S  = "${WORKDIR}/git"

meta/recipes-devtools/binutils/binutils/0017-dlltool-file-name-too-long.patch

@@ -0,0 +1,208 @@
+From d95d8395b3a533461f46e8b7e55fef540fc2621b Mon Sep 17 00:00:00 2001
+From: Jiaying Song <jiaying.song.cn@windriver.com>
+Date: Tue, 13 Aug 2024 10:31:21 +0800
+Subject: [PATCH] dlltool: file name too long
+
+During the execution of the command: i686-w64-mingw32-dlltool
+--input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe
+An error occurred:
+i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_plugin_api_a_h.s
+
+Due to the path length exceeding the Linux system's file name length
+limit (NAME_MAX=255), the temporary file name generated by the
+i686-w64-mingw32-dlltool command becomes too long to open. To address
+this, a new temporary file name prefix is generated using tmp_prefix =
+prefix_encode ("d", getpid()), ensuring that the file name does not
+exceed the system's length limit.
+
+Upstream-Status: Backport
+[https://github.com/bminor/binutils-gdb/commit/a253bea8995323201b016fe477280c1782688ab4]
+
+Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
+Reviewed-by: Alan Modra <amodra@gmail.com>
+
+Allow for "snnnnn.o" suffix when testing against NAME_MAX, and tidy
+TMP_STUB handling by overwriting a prior nnnnn.o string rather than
+copying the entire name.
+
+* dlltool.c (TMP_STUB): Add "nnnnn.o" to format.
+(make_one_lib_file): Localise variables.  Don't copy TMP_STUB,
+overwrite suffix instead.
+(gen_lib_file): Similarly.
+(main): Allow for max suffix when testing against NAME_MAX.
+
+Upstream-Status: Backport
+[https://github.com/bminor/binutils-gdb/commit/d0285cdf58adf04e861cd1687f7ecec65937c99d]
+
+Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
+---
+ binutils/dlltool.c | 64 +++++++++++++++++-----------------------------
+ 1 file changed, 24 insertions(+), 40 deletions(-)
+
+diff --git a/binutils/dlltool.c b/binutils/dlltool.c
+index 066c99a4..94f6c34b 100644
+--- a/binutils/dlltool.c
++++ b/binutils/dlltool.c
+@@ -498,7 +498,7 @@ char *tmp_stub_buf;
+ #define TMP_HEAD_O	dlltmp (&tmp_head_o_buf, "%sh.o")
+ #define TMP_TAIL_S	dlltmp (&tmp_tail_s_buf, "%st.s")
+ #define TMP_TAIL_O	dlltmp (&tmp_tail_o_buf, "%st.o")
+-#define TMP_STUB	dlltmp (&tmp_stub_buf, "%ss")
++#define TMP_STUB	dlltmp (&tmp_stub_buf, "%ssnnnnn.o")
+ 
+ /* This bit of assembly does jmp * ....  */
+ static const unsigned char i386_jtab[] =
+@@ -2401,26 +2401,11 @@ make_imp_label (const char *prefix, const char *name)
+ static bfd *
+ make_one_lib_file (export_type *exp, int i, int delay)
+ {
+-  bfd *      abfd;
+-  asymbol *  exp_label;
+-  asymbol *  iname = 0;
+-  asymbol *  iname2;
+-  asymbol *  iname_lab;
+-  asymbol ** iname_lab_pp;
+-  asymbol ** iname_pp;
+-#ifndef EXTRA
+-#define EXTRA    0
+-#endif
+-  asymbol *  ptrs[NSECS + 4 + EXTRA + 1];
+-  flagword   applicable;
+-  char *     outname = xmalloc (strlen (TMP_STUB) + 10);
+-  int        oidx = 0;
+-
+-
+-  sprintf (outname, "%s%05d.o", TMP_STUB, i);
+-
+-  abfd = bfd_openw (outname, HOW_BFD_WRITE_TARGET);
++  char *outname = TMP_STUB;
++  size_t name_len = strlen (outname);
++  sprintf (outname + name_len - 7, "%05d.o", i);
+ 
++  bfd *abfd = bfd_openw (outname, HOW_BFD_WRITE_TARGET);
+   if (!abfd)
+     /* xgettext:c-format */
+     fatal (_("bfd_open failed open stub file: %s: %s"),
+@@ -2437,9 +2422,13 @@ make_one_lib_file (export_type *exp, int i, int delay)
+     bfd_set_private_flags (abfd, F_INTERWORK);
+ #endif
+ 
+-  applicable = bfd_applicable_section_flags (abfd);
+-
+   /* First make symbols for the sections.  */
++  flagword applicable = bfd_applicable_section_flags (abfd);
++#ifndef EXTRA
++#define EXTRA    0
++#endif
++  asymbol *ptrs[NSECS + 4 + EXTRA + 1];
++  int oidx = 0;
+   for (i = 0; i < NSECS; i++)
+     {
+       sinfo *si = secdata + i;
+@@ -2466,7 +2455,7 @@ make_one_lib_file (export_type *exp, int i, int delay)
+ 
+   if (! exp->data)
+     {
+-      exp_label = bfd_make_empty_symbol (abfd);
++      asymbol *exp_label = bfd_make_empty_symbol (abfd);
+       exp_label->name = make_imp_label ("", exp->name);
+       exp_label->section = secdata[TEXT].sec;
+       exp_label->flags = BSF_GLOBAL;
+@@ -2482,6 +2471,7 @@ make_one_lib_file (export_type *exp, int i, int delay)
+   /* Generate imp symbols with one underscore for Microsoft
+      compatibility, and with two underscores for backward
+      compatibility with old versions of cygwin.  */
++  asymbol *iname = NULL;
+   if (create_compat_implib)
+     {
+       iname = bfd_make_empty_symbol (abfd);
+@@ -2491,25 +2481,24 @@ make_one_lib_file (export_type *exp, int i, int delay)
+       iname->value = 0;
+     }
+ 
+-  iname2 = bfd_make_empty_symbol (abfd);
++  asymbol *iname2 = bfd_make_empty_symbol (abfd);
+   iname2->name = make_imp_label ("__imp_", exp->name);
+   iname2->section = secdata[IDATA5].sec;
+   iname2->flags = BSF_GLOBAL;
+   iname2->value = 0;
+ 
+-  iname_lab = bfd_make_empty_symbol (abfd);
+-
++  asymbol *iname_lab = bfd_make_empty_symbol (abfd);
+   iname_lab->name = head_label;
+   iname_lab->section = bfd_und_section_ptr;
+   iname_lab->flags = 0;
+   iname_lab->value = 0;
+ 
+-  iname_pp = ptrs + oidx;
++  asymbol **iname_pp = ptrs + oidx;
+   if (create_compat_implib)
+     ptrs[oidx++] = iname;
+   ptrs[oidx++] = iname2;
+ 
+-  iname_lab_pp = ptrs + oidx;
++  asymbol **iname_lab_pp = ptrs + oidx;
+   ptrs[oidx++] = iname_lab;
+ 
+   ptrs[oidx] = 0;
+@@ -3089,29 +3078,26 @@ gen_lib_file (int delay)
+ 
+   if (dontdeltemps < 2)
+     {
+-      char *name;
+-      size_t stub_len = strlen (TMP_STUB);
++      char *name = TMP_STUB;
++      size_t name_len = strlen (name);
+ 
+-      name = xmalloc (stub_len + 10);
+-      memcpy (name, TMP_STUB, stub_len);
+       for (i = 0; (exp = d_exports_lexically[i]); i++)
+ 	{
+ 	  /* Don't delete non-existent stubs for PRIVATE entries.  */
+           if (exp->private)
+ 	    continue;
+-	  sprintf (name + stub_len, "%05d.o", i);
++	  sprintf (name + name_len - 7, "%05d.o", i);
+ 	  if (unlink (name) < 0)
+ 	    /* xgettext:c-format */
+ 	    non_fatal (_("cannot delete %s: %s"), name, strerror (errno));
+ 	  if (ext_prefix_alias)
+ 	    {
+-	      sprintf (name + stub_len, "%05d.o", i + PREFIX_ALIAS_BASE);
++	      sprintf (name + name_len - 7, "%05d.o", i + PREFIX_ALIAS_BASE);
+ 	      if (unlink (name) < 0)
+ 		/* xgettext:c-format */
+ 		non_fatal (_("cannot delete %s: %s"), name, strerror (errno));
+ 	    }
+ 	}
+-      free (name);
+     }
+ 
+   inform (_("Created lib file"));
+@@ -4096,9 +4082,9 @@ main (int ac, char **av)
+   if (tmp_prefix == NULL)
+     {
+       /* If possible use a deterministic prefix.  */
+-      if (imp_name || delayimp_name)
++      const char *input = imp_name ? imp_name : delayimp_name;
++      if (input && strlen (input) + sizeof ("_snnnnn.o") - 1 <= NAME_MAX)
+         {
+-          const char *input = imp_name ? imp_name : delayimp_name;
+           tmp_prefix = xmalloc (strlen (input) + 2);
+           sprintf (tmp_prefix, "%s_", input);
+           for (i = 0; tmp_prefix[i]; i++)
+@@ -4106,9 +4092,7 @@ main (int ac, char **av)
+               tmp_prefix[i] = '_';
+         }
+       else
+-        {
+-          tmp_prefix = prefix_encode ("d", getpid ());
+-        }
++        tmp_prefix = prefix_encode ("d", getpid ());
+     }
+ 
+   mangle_defs ();
+-- 
+2.34.1
+

meta/recipes-devtools/binutils/binutils/0018-CVE-2025-0840.patch

@@ -0,0 +1,53 @@
+Author: Alan Modra <amodra@gmail.com>
+Date:   Wed, 15 Jan 2025 19:13:43 +1030
+
+PR32560 stack-buffer-overflow at objdump disassemble_bytes
+
+There's always someone pushing the boundaries.
+
+	PR 32560
+	* objdump.c (MAX_INSN_WIDTH): Define.
+	(insn_width): Make it an unsigned long.
+	(disassemble_bytes): Use MAX_INSN_WIDTH to size buffer.
+	(main <OPTION_INSN_WIDTH>): Restrict size of insn_width.
+
+Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=baac6c221e9d69335bf41366a1c7d87d8ab2f893]
+CVE: CVE-2025-0840
+
+Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
+
+diff --git a/binutils/objdump.c b/binutils/objdump.c
+index 49e944b1..dba726e3 100644
+--- a/binutils/objdump.c
++++ b/binutils/objdump.c
+@@ -116,7 +116,8 @@ static bool disassemble_all;		/* -D */
+ static int disassemble_zeroes;		/* --disassemble-zeroes */
+ static bool formats_info;		/* -i */
+ int wide_output;			/* -w */
+-static int insn_width;			/* --insn-width */
++#define MAX_INSN_WIDTH 49
++static unsigned long insn_width;       /* --insn-width */
+ static bfd_vma start_address = (bfd_vma) -1; /* --start-address */
+ static bfd_vma stop_address = (bfd_vma) -1;  /* --stop-address */
+ static int dump_debugging;		/* --debugging */
+@@ -3327,7 +3328,7 @@ disassemble_bytes (struct disassemble_info *inf,
+ 	}
+       else
+ 	{
+-	  char buf[50];
++	  char buf[MAX_INSN_WIDTH + 1];
+ 	  unsigned int bpc = 0;
+ 	  unsigned int pb = 0;
+ 
+@@ -5995,8 +5996,9 @@ main (int argc, char **argv)
+ 	  break;
+ 	case OPTION_INSN_WIDTH:
+ 	  insn_width = strtoul (optarg, NULL, 0);
+-	  if (insn_width <= 0)
+-	    fatal (_("error: instruction width must be positive"));
++	  if (insn_width - 1 >= MAX_INSN_WIDTH)
++	    fatal (_("error: instruction width must be in the range 1 to "
++	             XSTRING (MAX_INSN_WIDTH)));
+ 	  break;
+ 	case OPTION_INLINES:
+ 	  unwind_inlines = true;

meta/recipes-devtools/elfutils/elfutils_0.191.bb

@@ -23,6 +23,9 @@ SRC_URI = "https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
            file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \
            file://0001-debuginfod-Remove-unused-variable.patch \
            file://0001-srcfiles-fix-unused-variable-BUFFER_SIZE.patch \
+           file://CVE-2025-1352.patch \
+           file://CVE-2025-1365.patch \
+           file://CVE-2025-1372.patch \
            "
 SRC_URI:append:libc-musl = " \
            file://0003-musl-utils.patch \

meta/recipes-devtools/elfutils/files/CVE-2025-1352.patch

@@ -0,0 +1,153 @@
+From 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard <mark@klomp.org>
+Date: Sat, 8 Feb 2025 20:00:12 +0100
+Subject: [PATCH] libdw: Simplify __libdw_getabbrev and fix dwarf_offabbrev
+ issue
+
+__libdw_getabbrev could crash on reading a bad abbrev by trying to
+deallocate memory it didn't allocate itself. This could happen because
+dwarf_offabbrev would supply its own memory when calling
+__libdw_getabbrev. No other caller did this.
+
+Simplify the __libdw_getabbrev common code by not taking external
+memory to put the abbrev result in (this would also not work correctly
+if the abbrev was already cached). And make dwarf_offabbrev explicitly
+copy the result (if there was no error or end of abbrev).
+
+     * libdw/dwarf_getabbrev.c (__libdw_getabbrev): Don't take
+     Dwarf_Abbrev result argument. Always just allocate abb when
+     abbrev not found in cache.
+     (dwarf_getabbrev): Don't pass NULL as last argument to
+     __libdw_getabbrev.
+    * libdw/dwarf_tag.c (__libdw_findabbrev): Likewise.
+    * libdw/dwarf_offabbrev.c (dwarf_offabbrev): Likewise. And copy
+    abbrev into abbrevp on success.
+    * libdw/libdw.h (dwarf_offabbrev): Document return values.
+    * libdw/libdwP.h (__libdw_getabbrev): Don't take Dwarf_Abbrev
+    result argument.
+
+https://sourceware.org/bugzilla/show_bug.cgi?id=32650
+
+Signed-off-by: Mark Wielaard <mark@klomp.org>
+
+Upstream-Status: Backport [https://sourceware.org/git/?p=elfutils.git;a=commit;h=2636426a091bd6c6f7f02e49ab20d4cdc6bfc753]
+CVE: CVE-2025-1352
+Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
+---
+ libdw/dwarf_getabbrev.c | 12 ++++--------
+ libdw/dwarf_offabbrev.c | 10 +++++++---
+ libdw/dwarf_tag.c       |  3 +--
+ libdw/libdw.h           |  4 +++-
+ libdw/libdwP.h          |  3 +--
+ 5 files changed, 16 insertions(+), 16 deletions(-)
+
+diff --git a/libdw/dwarf_getabbrev.c b/libdw/dwarf_getabbrev.c
+index 5b02333..d9a6c02 100644
+--- a/libdw/dwarf_getabbrev.c
++++ b/libdw/dwarf_getabbrev.c
+@@ -1,5 +1,6 @@
+ /* Get abbreviation at given offset.
+    Copyright (C) 2003, 2004, 2005, 2006, 2014, 2017 Red Hat, Inc.
++   Copyright (C) 2025 Mark J. Wielaard <mark@klomp.org>
+    This file is part of elfutils.
+    Written by Ulrich Drepper <drepper@redhat.com>, 2003.
+ 
+@@ -38,7 +39,7 @@
+ Dwarf_Abbrev *
+ internal_function
+ __libdw_getabbrev (Dwarf *dbg, struct Dwarf_CU *cu, Dwarf_Off offset,
+-		   size_t *lengthp, Dwarf_Abbrev *result)
++		   size_t *lengthp)
+ {
+   /* Don't fail if there is not .debug_abbrev section.  */
+   if (dbg->sectiondata[IDX_debug_abbrev] == NULL)
+@@ -85,12 +86,7 @@ __libdw_getabbrev (Dwarf *dbg, struct Dwarf_CU *cu, Dwarf_Off offset,
+   Dwarf_Abbrev *abb = NULL;
+   if (cu == NULL
+       || (abb = Dwarf_Abbrev_Hash_find (&cu->abbrev_hash, code)) == NULL)
+-    {
+-      if (result == NULL)
+-	abb = libdw_typed_alloc (dbg, Dwarf_Abbrev);
+-      else
+-	abb = result;
+-    }
++    abb = libdw_typed_alloc (dbg, Dwarf_Abbrev);
+   else
+     {
+       foundit = true;
+@@ -183,5 +179,5 @@ dwarf_getabbrev (Dwarf_Die *die, Dwarf_Off offset, size_t *lengthp)
+       return NULL;
+     }
+ 
+-  return __libdw_getabbrev (dbg, cu, abbrev_offset + offset, lengthp, NULL);
++  return __libdw_getabbrev (dbg, cu, abbrev_offset + offset, lengthp);
+ }
+diff --git a/libdw/dwarf_offabbrev.c b/libdw/dwarf_offabbrev.c
+index 27cdad6..41df69b 100644
+--- a/libdw/dwarf_offabbrev.c
++++ b/libdw/dwarf_offabbrev.c
+@@ -41,11 +41,15 @@ dwarf_offabbrev (Dwarf *dbg, Dwarf_Off offset, size_t *lengthp,
+   if (dbg == NULL)
+     return -1;
+ 
+-  Dwarf_Abbrev *abbrev = __libdw_getabbrev (dbg, NULL, offset, lengthp,
+-					    abbrevp);
++  Dwarf_Abbrev *abbrev = __libdw_getabbrev (dbg, NULL, offset, lengthp);
+ 
+   if (abbrev == NULL)
+     return -1;
+ 
+-  return abbrev == DWARF_END_ABBREV ? 1 : 0;
++  if (abbrev == DWARF_END_ABBREV)
++    return 1;
++
++  *abbrevp = *abbrev;
++
++  return 0;
+ }
+diff --git a/libdw/dwarf_tag.c b/libdw/dwarf_tag.c
+index d784970..218382a 100644
+--- a/libdw/dwarf_tag.c
++++ b/libdw/dwarf_tag.c
+@@ -53,8 +53,7 @@ __libdw_findabbrev (struct Dwarf_CU *cu, unsigned int code)
+ 
+ 	/* Find the next entry.  It gets automatically added to the
+ 	   hash table.  */
+-	abb = __libdw_getabbrev (cu->dbg, cu, cu->last_abbrev_offset, &length,
+-				 NULL);
++	abb = __libdw_getabbrev (cu->dbg, cu, cu->last_abbrev_offset, &length);
+ 	if (abb == NULL || abb == DWARF_END_ABBREV)
+ 	  {
+ 	    /* Make sure we do not try to search for it again.  */
+diff --git a/libdw/libdw.h b/libdw/libdw.h
+index d53dc78..ec4713a 100644
+--- a/libdw/libdw.h
++++ b/libdw/libdw.h
+@@ -587,7 +587,9 @@ extern int dwarf_srclang (Dwarf_Die *die);
+ extern Dwarf_Abbrev *dwarf_getabbrev (Dwarf_Die *die, Dwarf_Off offset,
+ 				      size_t *lengthp);
+ 
+-/* Get abbreviation at given offset in .debug_abbrev section.  */
++/* Get abbreviation at given offset in .debug_abbrev section.  On
++   success return zero and fills in ABBREVP.  When there is no (more)
++   abbrev at offset returns one.  On error returns a negative value.  */
+ extern int dwarf_offabbrev (Dwarf *dbg, Dwarf_Off offset, size_t *lengthp,
+ 			    Dwarf_Abbrev *abbrevp)
+      __nonnull_attribute__ (4);
+diff --git a/libdw/libdwP.h b/libdw/libdwP.h
+index 8b2f06f..f0f4b78 100644
+--- a/libdw/libdwP.h
++++ b/libdw/libdwP.h
+@@ -783,8 +783,7 @@ extern Dwarf_Abbrev *__libdw_findabbrev (struct Dwarf_CU *cu,
+ 
+ /* Get abbreviation at given offset.  */
+ extern Dwarf_Abbrev *__libdw_getabbrev (Dwarf *dbg, struct Dwarf_CU *cu,
+-					Dwarf_Off offset, size_t *lengthp,
+-					Dwarf_Abbrev *result)
++					Dwarf_Off offset, size_t *lengthp)
+      __nonnull_attribute__ (1) internal_function;
+ 
+ /* Get abbreviation of given DIE, and optionally set *READP to the DIE memory
+-- 
+2.25.1
+

meta/recipes-devtools/elfutils/files/CVE-2025-1365.patch

@@ -0,0 +1,151 @@
+From 5e5c0394d82c53e97750fe7b18023e6f84157b81 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard <mark@klomp.org>
+Date: Sat, 8 Feb 2025 21:44:56 +0100
+Subject: [PATCH] libelf, readelf: Use validate_str also to check dynamic
+ symstr data
+
+When dynsym/str was read through eu-readelf --dynamic by readelf
+process_symtab the string data was not validated, possibly printing
+unallocated memory past the end of the symstr data. Fix this by
+turning the elf_strptr validate_str function into a generic
+lib/system.h helper function and use it in readelf to validate the
+strings before use.
+
+	* libelf/elf_strptr.c (validate_str): Remove to...
+	* lib/system.h (validate_str): ... here. Make inline, simplify
+	check and document.
+	* src/readelf.c (process_symtab): Use validate_str on symstr_data.
+
+https://sourceware.org/bugzilla/show_bug.cgi?id=32654
+
+Signed-off-by: Mark Wielaard <mark@klomp.org>
+
+Upstream-Status: Backport [https://sourceware.org/git/?p=elfutils.git;a=commit;h=5e5c0394d82c53e97750fe7b18023e6f84157b81]
+CVE: CVE-2025-1365
+Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
+---
+ lib/system.h        | 27 +++++++++++++++++++++++++++
+ libelf/elf_strptr.c | 18 ------------------
+ src/readelf.c       | 18 +++++++++++++++---
+ 3 files changed, 42 insertions(+), 21 deletions(-)
+
+diff --git a/lib/system.h b/lib/system.h
+index 0db12d9..0698e5f 100644
+--- a/lib/system.h
++++ b/lib/system.h
+@@ -34,6 +34,7 @@
+ #include <config.h>
+ 
+ #include <errno.h>
++#include <stdbool.h>
+ #include <stddef.h>
+ #include <stdint.h>
+ #include <string.h>
+@@ -117,6 +118,32 @@ startswith (const char *str, const char *prefix)
+   return strncmp (str, prefix, strlen (prefix)) == 0;
+ }
+ 
++/* Return TRUE if STR[FROM] is a valid string with a zero terminator
++   at or before STR[TO - 1].  Note FROM is an index into the STR
++   array, while TO is the maximum size of the STR array.  This
++   function returns FALSE when TO is zero or FROM >= TO.  */
++static inline bool
++validate_str (const char *str, size_t from, size_t to)
++{
++#if HAVE_DECL_MEMRCHR
++  // Check end first, which is likely a zero terminator,
++  // to prevent function call
++  return (to > 0
++	  && (str[to - 1] == '\0'
++	      || (to > from
++		  && memrchr (&str[from], '\0', to - from - 1) != NULL)));
++#else
++  do {
++    if (to <= from)
++      return false;
++
++    to--;
++  } while (str[to]);
++
++  return true;
++#endif
++}
++
+ /* A special gettext function we use if the strings are too short.  */
+ #define sgettext(Str) \
+   ({ const char *__res = strrchr (_(Str), '|');			      \
+diff --git a/libelf/elf_strptr.c b/libelf/elf_strptr.c
+index 79a24d2..c5a94f8 100644
+--- a/libelf/elf_strptr.c
++++ b/libelf/elf_strptr.c
+@@ -53,24 +53,6 @@ get_zdata (Elf_Scn *strscn)
+   return zdata;
+ }
+ 
+-static bool validate_str (const char *str, size_t from, size_t to)
+-{
+-#if HAVE_DECL_MEMRCHR
+-  // Check end first, which is likely a zero terminator, to prevent function call
+-  return ((to > 0 && str[to - 1]  == '\0')
+-	  || (to - from > 0 && memrchr (&str[from], '\0', to - from - 1) != NULL));
+-#else
+-  do {
+-    if (to <= from)
+-      return false;
+-
+-    to--;
+-  } while (str[to]);
+-
+-  return true;
+-#endif
+-}
+-
+ char *
+ elf_strptr (Elf *elf, size_t idx, size_t offset)
+ {
+diff --git a/src/readelf.c b/src/readelf.c
+index 0e93118..63eb548 100644
+--- a/src/readelf.c
++++ b/src/readelf.c
+@@ -2639,6 +2639,7 @@ process_symtab (Ebl *ebl, unsigned int nsyms, Elf64_Word idx,
+       char typebuf[64];
+       char bindbuf[64];
+       char scnbuf[64];
++      const char *sym_name;
+       Elf32_Word xndx;
+       GElf_Sym sym_mem;
+       GElf_Sym *sym
+@@ -2650,6 +2651,19 @@ process_symtab (Ebl *ebl, unsigned int nsyms, Elf64_Word idx,
+       /* Determine the real section index.  */
+       if (likely (sym->st_shndx != SHN_XINDEX))
+         xndx = sym->st_shndx;
++      if (use_dynamic_segment == true)
++	{
++	  if (validate_str (symstr_data->d_buf, sym->st_name,
++			    symstr_data->d_size))
++	    sym_name = (char *)symstr_data->d_buf + sym->st_name;
++	  else
++	    sym_name = NULL;
++	}
++      else
++	sym_name = elf_strptr (ebl->elf, idx, sym->st_name);
++
++      if (sym_name == NULL)
++	sym_name = "???";
+ 
+       printf (_ ("\
+ %5u: %0*" PRIx64 " %6" PRId64 " %-7s %-6s %-9s %6s %s"),
+@@ -2662,9 +2676,7 @@ process_symtab (Ebl *ebl, unsigned int nsyms, Elf64_Word idx,
+               get_visibility_type (GELF_ST_VISIBILITY (sym->st_other)),
+               ebl_section_name (ebl, sym->st_shndx, xndx, scnbuf,
+                                 sizeof (scnbuf), NULL, shnum),
+-              use_dynamic_segment == true
+-                  ? (char *)symstr_data->d_buf + sym->st_name
+-                  : elf_strptr (ebl->elf, idx, sym->st_name));
++              sym_name);
+ 
+       if (versym_data != NULL)
+         {
+-- 
+2.25.1
+

meta/recipes-devtools/elfutils/files/CVE-2025-1372.patch

@@ -0,0 +1,50 @@
+From 73db9d2021cab9e23fd734b0a76a612d52a6f1db Mon Sep 17 00:00:00 2001
+From: Mark Wielaard <mark@klomp.org>
+Date: Sun, 9 Feb 2025 00:07:39 +0100
+Subject: [PATCH] readelf: Skip trying to uncompress sections without a name
+
+When combining eu-readelf -z with -x or -p to dump the data or strings
+in an (corrupted ELF) unnamed numbered section eu-readelf could crash
+trying to check whether the section name starts with .zdebug. Fix this
+by skipping sections without a name.
+
+   * src/readelf.c (dump_data_section): Don't try to gnu decompress a
+   section without a name.
+   (print_string_section): Likewise.
+
+https://sourceware.org/bugzilla/show_bug.cgi?id=32656
+
+Signed-off-by: Mark Wielaard <mark@klomp.org>
+
+Upstream-Status: Backport [https://sourceware.org/git/?p=elfutils.git;a=commit;h=73db9d2021cab9e23fd734b0a76a612d52a6f1db]
+CVE: CVE-2025-1372
+Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
+---
+ src/readelf.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/readelf.c b/src/readelf.c
+index 63eb548..fc04556 100644
+--- a/src/readelf.c
++++ b/src/readelf.c
+@@ -13327,7 +13327,7 @@ dump_data_section (Elf_Scn *scn, const GElf_Shdr *shdr, const char *name)
+ 			_("Couldn't uncompress section"),
+ 			elf_ndxscn (scn));
+ 	    }
+-	  else if (startswith (name, ".zdebug"))
++	  else if (name && startswith (name, ".zdebug"))
+ 	    {
+ 	      if (elf_compress_gnu (scn, 0, 0) < 0)
+ 		printf ("WARNING: %s [%zd]\n",
+@@ -13378,7 +13378,7 @@ print_string_section (Elf_Scn *scn, const GElf_Shdr *shdr, const char *name)
+ 			_("Couldn't uncompress section"),
+ 			elf_ndxscn (scn));
+ 	    }
+-	  else if (startswith (name, ".zdebug"))
++	  else if (name && startswith (name, ".zdebug"))
+ 	    {
+ 	      if (elf_compress_gnu (scn, 0, 0) < 0)
+ 		printf ("WARNING: %s [%zd]\n",
+-- 
+2.25.1
+

meta/recipes-devtools/go/go-1.22.12.inc

@@ -15,4 +15,4 @@ SRC_URI += "\
     file://0008-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch \
     file://0009-go-Filter-build-paths-on-staticly-linked-arches.patch \
 "
-SRC_URI[main.sha256sum] = "df12c23ebf19dea0f4bf46a22cbeda4a3eca6f474f318390ce774974278440b8"
+SRC_URI[main.sha256sum] = "012a7e1f37f362c0918c1dfa3334458ac2da1628c4b9cf4d9ca02db986e17d71"

meta/recipes-devtools/go/go-binary-native_1.22.12.bb

@@ -9,9 +9,9 @@ PROVIDES = "go-native"
 
 # Checksums available at https://go.dev/dl/
 SRC_URI = "https://dl.google.com/go/go${PV}.${BUILD_GOOS}-${BUILD_GOARCH}.tar.gz;name=go_${BUILD_GOTUPLE}"
-SRC_URI[go_linux_amd64.sha256sum] = "5f467d29fc67c7ae6468cb6ad5b047a274bae8180cac5e0b7ddbfeba3e47e18f"
-SRC_URI[go_linux_arm64.sha256sum] = "5c616b32dab04bb8c4c8700478381daea0174dc70083e4026321163879278a4a"
-SRC_URI[go_linux_ppc64le.sha256sum] = "c546f27866510bf8e54e86fe6f58c705af0e894341e5572c91f197a734152c27"
+SRC_URI[go_linux_amd64.sha256sum] = "4fa4f869b0f7fc6bb1eb2660e74657fbf04cdd290b5aef905585c86051b34d43"
+SRC_URI[go_linux_arm64.sha256sum] = "fd017e647ec28525e86ae8203236e0653242722a7436929b1f775744e26278e7"
+SRC_URI[go_linux_ppc64le.sha256sum] = "9573d30003b0796717a99d9e2e96c48fddd4fc0f29d840f212c503b03d7de112"
 
 UPSTREAM_CHECK_URI = "https://golang.org/dl/"
 UPSTREAM_CHECK_REGEX = "go(?P<pver>\d+(\.\d+)+)\.linux"