vulnerabitilies: add section for kernel CVEs vulnerabilities

From: Daniel Turull <daniel.turull@ericsson.com>

Documentation to include how to use scripts that can help
with kernel CVEs introduce by:

e60b1759c1 improve_kernel_cve_report: add script for postprocesing of kernel CVE data
12612e8680 linux/generate-cve-exclusions: use data from CVEProject

Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 documentation/dev-manual/vulnerabilities.rst | 108 +++++++++++++++++++
 1 file changed, 108 insertions(+)

Hi,

For the whole patch, please wrap lines to 80 chars as described here:
https://git.yoctoproject.org/yocto-docs/tree/documentation/standards.md#n50

On Tue Oct 28, 2025 at 10:41 AM CET, Daniel Turull via lists.yoctoproject.org wrote:
> From: Daniel Turull <daniel.turull@ericsson.com>
>
> Documentation to include how to use scripts that can help
> with kernel CVEs introduce by:
>
> e60b1759c1 improve_kernel_cve_report: add script for postprocesing of kernel CVE data
> 12612e8680 linux/generate-cve-exclusions: use data from CVEProject
>
> Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
> ---
>  documentation/dev-manual/vulnerabilities.rst | 108 +++++++++++++++++++
>  1 file changed, 108 insertions(+)
>
> diff --git a/documentation/dev-manual/vulnerabilities.rst b/documentation/dev-manual/vulnerabilities.rst
> index 6cc7f0494..065d853d6 100644
> --- a/documentation/dev-manual/vulnerabilities.rst
> +++ b/documentation/dev-manual/vulnerabilities.rst
> @@ -335,3 +335,111 @@ When analyzing CVEs, it is recommended to:
>  -  follow public `open source security mailing lists <https://oss-security.openwall.org/wiki/mailing-lists>`__ for
>     discussions and advance notifications of CVE bugs and software releases with fixes.
>  
> +Linux kernel vulnerabilities
> +============================
> +
> +Since the Linux kernel became a CVE Numbering Authority (CNA), the number of associated CVEs has increased dramatically. Security teams must address these CVEs to meet regulatory and customer requirements. Automation on identifying issue helps to reduce their workload.
> +
> +OpenEmbedded-core has two scripts that helps to characterize and filter CVEs that affects the Linux kernel, which use one of the following CVE sources:
> +
> +- https://git.kernel.org/pub/scm/linux/security/vulns.git
> +- https://github.com/CVEProject/cvelistV5
> +
> +The scripts' location are:

> +
> +-  ``openembedded-core/meta/recipes-kernel/linux/generate-cve-exclusions.py``
> +-  ``openembedded-core/scripts/contrib/improve_kernel_cve_report.py`

I would suggest rephrasing as follows:

"""
:term:`OpenEmbedded-Core (OE-Core)` has two scripts that help to characterize
and filter CVEs that affect the Linux kernel:

-  ``meta/recipes-kernel/linux/generate-cve-exclusions.py``
-  ``scripts/contrib/improve_kernel_cve_report.py`

Which use one of the following CVE sources:

-  https://git.kernel.org/pub/scm/linux/security/vulns.git
-  https://github.com/CVEProject/cvelistV5
"""

Are the two sources used by both scripts?

> +
> +generate-cve-exclusions.py

Enclose with ``:

``generate-cve-exclusions.py``

> +--------------------------
> +
> +When updating a kernel recipe, a helper script needs to be run manually to update the CVE_STATUS for the kernel recipe. The script can be used for custom kernels. Run it as follows::

Try to enclose yocto variables with :term:`...`, so readers can jump to its
definition easily. Here: :term:`CVE_STATUS`.

> +
> +   openembedded-core/meta/recipes-kernel/linux/generate-cve-exclusions.py <datadir> <version> > cve-exclusion_<kernel_version>.inc

Can you elaborate on <datadir>? Does this directory need to be created
beforehand? Does it need to be populated with anything, or is it the directory
where some temporary data is stored?

> +Example::
> +
> +   cd openembedded-core/meta/recipes-kernel/linux/
> +   ./generate-cve-exclusions.py ~/cvelistV5 6.12.27 > cve-exclusion_6.12.inc

Maybe I would avoid showing an example that modifies openembedded-core?

Instead:

   ./openembedded-core/meta/recipes-kernel/linux/generate-cve-exclusions.py ~/cvelistV5 6.12.27 > meta-custom/recipes-kernel/linux/cve-exclusion_6.12.inc

> +
> +Then the CVE information will automatically be added in the :ref:`ref-classes-cve-check` or :ref:`ref-classes-vex` report.

That's only if your kernel recipe is including the file, right? This is the case
for linux-yocto, but since you mentioned above that custom kernels can be used,
I would add that this file needs to be included in the kernel recipe with:

   include cve-exclusion_6.12.inc

Unless I missed something!

> +improve_kernel_cve_report.py
> +-----------------------------

Enclose with ``:

``improve_kernel_cve_report.py``

> +
> +The script in ``openembedded-core/scripts/contrib/improve_kernel_cve_report.py`` leverages CVE kernel metadata and the :term:`SPDX_INCLUDE_COMPILED_SOURCES` 


the :term:`SPDX_INCLUDE_COMPILED_SOURCES` variable

> +to update the ``cve-summary.json``

file.

> +It reduces CVE false positives by 70%-80% and provide detailed responses for all kernel-related CVEs, with the files used to build the kernel. 

s/, with the files used to/by using the files used to/

> +The script is decoupled from the build and can be run outside BitBake.

Suggestion:

s/outside BitBake/outside of the :term:`BitBake` environment/

> +
> +The script uses the output from

the

> +:ref:`ref-classes-vex` or :ref:`ref-classes-cve-check` class as input, together with CVE information from the Linux kernel CNA to enrich the ``cve-summary.json``

file.

What is this file? Where does it come from? 

Maybe say "a ``cve-summary.json`` file with updated CVE information."

> +It creates a new json file with updated CVE information. 

And remove this sentence, if this new JSON file is cve-summary.json?

> +Optionally, it can also use the list of compiled files from the kernel :term:`SPDX` to ignore CVEs that are not affected because the files are not compiled.
> +
> +BitBake uses the debug information to extract the sources used to build a

"For this, BitBake uses the debug information..."

> +binary. Therefore, it needs to be configured in the kernel to extract the
> +kernel compiled files. Enable it by adding the following in your
> +``local.conf`` or kernel recipe::

"""
If you are using the ``linux-yocto`` recipe, enable it by adding the following
in a :term:`configuration file` or in a ``.bbappend``::
"""

We try to avoid the bad practice of putting everything in local.conf.

> +
> +   KERNEL_EXTRA_FEATURES:append = " features/debug/debug-kernel.scc"
> +
> +Or by editing your kernel configuration to include DWARF4 debug information.

Please add:

"""
See the :ref:`kernel-dev/common:Changing the Configuration` section of the Yocto
Project Linux Kernel Development Manual for more information.
"""

And:

"""
For the following example, we will consider that the kernel recipe used is
``linux-yocto``. Instructions also apply to other kernel recipes named
differently.
"""

> +
> +The sources for the kernel are stored under
> +``tmp/pkgdata/<MACHINE>/debugsources/linux-yocto-debugsources.json.zstd``. In
> +order to include the information into the :term:`SPDX` file to filter out
> +source files that are not included in the binaries, 

Suggestion:

s/not included in the binaries/not used to compile the kernel/

> +add the following in your ``local.conf``::

"""
add the following in a :term:`configuration file`::
"""

> +
> +   SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"
> +
> +Finally, store either the ``recipe-linux-yocto.spdx.json`` or the ``linux-yocto-debugsources.json.zstd`` outside the build directory.

s/build directory/:term:`build directory`/

> +
> +The :term:`SPDX` file is under ``tmp/deploy/spdx/3.0.1/<MACHINE>/recipes/recipe-linux-yocto.spdx.json``

"""
is stored in ``tmp/deploy/spdx/<spdx_version>/<MACHINE>/recipes/recipe-linux-yocto.spdx.json``
(or ``
"""

Trying to avoid having to maintain the version here if it changes.

> +
> +Once you have the input data, first you need to clone or fetch the latest CVE information from kernel.org::
> +
> +   git clone https://git.kernel.org/pub/scm/linux/security/vulns.git
> +
> +Finally, run the script by using one of the examples bellow. The most exact

s/bellow/below/

> +are the first two examples, using the old cve-summary.json to identify the
> +kernel version.

"old" 

Maybe just "the ``cve-summary.json`` file" is enough?

> +
> +- Example using old-cve-report as input::

"""
Example using ``--old-cve-report``::
"""

> +
> +   python3 openembedded-core/scripts/contrib/improve_kernel_cve_report.py --spdx tmp/deploy/spdx/3.0.1/qemux86_64/recipes/recipe-linux-yocto.spdx.json --datadir ./vulns --old-cve-report build/tmp/log/cve/cve-summary.json

Assuming, but add:

"""
   The ``./vulns`` directory will be created if it does not exist.
"""

> +
> +- Example using debug-sources file instead of SPDX kernel file::

"""
Example using ``--debug-sources``::
"""

> +
> +   python3 openembedded-core/scripts/contrib/improve_kernel_cve_report.py --debug-sources tmp/pkgdata/qemux86_64/debugsources/linux-yocto-debugsources.json.zstd --datadir ./vulns --old-cve-report build/tmp/log/cve/cve-summary.json
> +
> +- Example using the kernel-version::

"""
Example using ``--kernel-version``::
"""

> +
> +   python3 openembedded-core/scripts/contrib/improve_kernel_cve_report.py --spdx tmp/deploy/spdx/3.0.1/qemux86_64/recipes/recipe-linux-yocto.spdx.json --kernel-version 6.12.27 --datadir ./vulns
> +
> +Example of output for a CVE that the binary does not include the source code due to the kernel configuration::

Suggestion:

"""
Example output for a CVE for which the status was changed to "Ignored" because
the source files associated to the CVE were not compiled::
"""

Also nitpick but maybe you can use

.. code-block:: json
   {
     "id": "CVE-2025-38384",
     "status": "Ignored",
     "detail": "not-applicable-config",
     "summary": "In the Linux kernel, the following vulnerability has been resolved (...)",
     "description": "Source code not compiled by config. {'drivers/mtd/nand/spi/core.c'}"
   }

So these snippets render with highlighting.

> +
> +        {
> +          "id": "CVE-2025-38384",
> +          "status": "Ignored",
> +          "detail": "not-applicable-config",
> +          "summary": "In the Linux kernel, the following vulnerability has been resolved (...),
> +          "description": "Source code not compiled by config. {'drivers/mtd/nand/spi/core.c'}"
> +        },
> +
> +Example of output for a CVE not in range::
> +
> +        {
> +          "id": "CVE-2025-40017",
> +          "status": "Patched",
> +          "detail": "fixed-version",
> +          "summary": "In the Linux kernel, the following vulnerability has been resolved (...),
> +          "description": "only affects 6.15 onwards"
> +        }
> +
> +Example of output for a CVE that is vulnerable::
> +
> +        {
> +          "id": "CVE-2024-58093",
> +          "status": "Unpatched",
> +          "detail": "version-in-range",
> +          "summary": "In the Linux kernel, the following vulnerability has been resolved (...),
> +          "description": "Needs backporting (fixed from 6.15)"
> +        }
> +
> +Example of output for a CVE rejected by the Linux CNA::
> +
> +        {
> +          "id": "CVE-2025-38380",
> +          "status": "Ignored",
> +          "detail": "rejected",
> +          "summary": "In the Linux kernel, the following vulnerability has been resolved (...),
> +          "description": "Rejected by CNA"
> +        }
> +

Thanks for documenting this!
Antonin