Review the last of the historical kernel CVEs. Issues which are
specific to other platforms or distributions are ignored in the kernel
recipe itself, whereas general security concerns like "ICMP leaks
information" and "USB has flaws" are ignored with more details in the
extra-exclusions file as before.
(From OE-Core rev: fe1c0b9725f88d15ba48b02b5fef01f2cf2e9d78)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These BlueZ issues were mislabelled as Linux issues, but now that the
CPE data is accurate this ignore can be removed.
(From OE-Core rev: 7f354aed364b17259a642cc97e30a0a2b8218134)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bulk of the historic kernel CVEs in this file are now handled by
the include files generated by linux/generate-cve-exclusions.py, so
remove them.
Those that remain date from 2017 or earlier, so rename the group to
'historic' and update the comment.
(From OE-Core rev: b46930641b9b5b38997b41ba8036e99387ed4225)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've a slew of CVE_CHECK_IGNOREs in cve-extra-exclusions which are to
mark a CVE as not valid with the current default kernel. However, this
file is kernel agnostic so if someone decides to build a 6.0 kernel then
these ignores are no longer valid.
Move the ignores which are to simply reflect backports to
cve-exclusions_6.1.inc so that they're version-specific. As the kernel
is upgraded these exclusions should be made redundant and removed from
the file.
(From OE-Core rev: 157f7b62e271df5dfd8a3bc4d3821bf806fde51e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the blanket ignore and handle the CVEs individually.
CVE-2019-14899 is related to network interface configuration across
multiple operating systems, so leave this as unresolved.
-3016, -3819 and -3887 are pending CPE updates, so ignore them.
The others have accurate CPE information now so are handled correctly.
(From OE-Core rev: e46bd62a278ec0bb9da995cab9350f1c363131d1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All of these CVEs have been fixed in the kernel point release that we
currently ship, so ignore them.
(From OE-Core rev: 86aee302673146dca10f313d0c70b69d6c4bdc7d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These CVEs have all been fixed <6.1.30, which is the default linux-yocto
kernel version.
(From OE-Core rev: 73f03970f0aadfb053666a1e93f6f6d5b5156ca6)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE-2023-1652 & CVE-2023-1829 are fixed by all version used by
linux-yocto.
Fixing commits are not referenced by NVD but are referenced by:
* https://www.linuxkernelcves.com
* Debian kernel-sec team
... this should be trust worthy enough.
(From OE-Core rev: 8f9d6c5b0238641313387c139442566752a1d25d)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add some information about some further kernel CVEs which don't apply for
either linux-yocto or don't apply for linux-yocto 6.1.
(From OE-Core rev: 85c1713bf0c01c68558bfba38edcc005c1ebb1c9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVEs CVE-2023-0179, CVE-2023-1079 and CVE-2023-1513 are patched in our
kernels but appear as active because the NVD database is not up to date.
(From OE-Core rev: ae1e7999a06c56c6f752413296b8f6b505475f8b)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Reviewed-by: Frank WOLFF <frank.wolff@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multiple CVEs are patched in kernel but appear as active because the NVD
database is not up to date.
In common file cve-extra-exclusion.inc, CVEs are ignored if and only if
all versions of kernel used are patched.
In cve-exclusion_6.1.inc, only ignore CVEs that are patched in v6.1,
and not patched in v5.15.
Recipes of version 6.1 should include this file.
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
(From OE-Core rev: 5feb065f1b1aaf218f71cc9d31a9251b139b9442)
Signed-off-by: Geoffrey GIRY <geoffrey.giry@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multiple CVE are patched in kernel but appears as active because the NVD
database is not up to date.
CVE are ignored if and only if all versions of kernel used by master are patched.
Also ignore CVEs with wrong CPE (applied to kernel but actually are for
another package)
(From OE-Core rev: 92770a08c04a6c1eb351231d937b16e76558f013)
Signed-off-by: Geoffrey GIRY <geoffrey.giry@smile.fr>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove obsolete comments/data from the file. Add in three CVEs to ignore.
Two are qemu CVEs which upstream aren't particularly intersted in and aren't
serious issues. Also ignore the nasm CVE found from fuzzing as this isn't
a issue we'd expose from OE.
(From OE-Core rev: 68291026aab2fa6ee1260ca95198dd1d568521e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For OE-Core our policy is to stay as close to the kernel stable releases
as we can. This should ensure the bulk of the major kernel CVEs are fixed
and we don't dive into each individual issue as the stable maintainers are
much more able to do that.
Rather than just ignore all kernel CVEs which is what we have been doing,
list the ones we ignore on this basis here, allowing new issues to be
visible. If anyone wishes to clean up CPE entries with NIST for these, we'd
welcome than and then entries can likely be removed from here.
(From OE-Core rev: 319d465d44328b5f062d2da0526c0e8b189b4239)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since Oracle relicensed bdb, the open source community is slowly but surely replacing bdb with
supported and open source friendly alternatives. As a result these CVEs are unlikely to ever be fixed.
(From OE-Core rev: 679fc70f907fb221f4541ebf30c1610e937209b7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE is effectively disputed - yes 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 and there is no security issue.
https://github.com/westes/flex/issues/414
(From OE-Core rev: 0cae5d7a24bedf6784781b62cbb3795a44bab4d1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The preferred methods for CVE resolution are:
1. Version upgrades where possible
2. Patches where not possible
3. Database updates where version info is incorrect
4. Exclusion from checking where it is determined that the CVE
does not apply to our environment
In some cases none of these methods are possible. For example the
CVE may be decades old with no apparent resolution, and with broken
links that make further research impractical. Some CVEs are vauge
with no specific action the project can take too.
This patch creates a mechanism for users to remove this type of
CVE from the cve-check results via an optional include file.
Based on an initial patch from Steve Sakoman <steve@sakoman.com>
but extended heavily by RP.
(From OE-Core rev: cf282ae03db3f09df42dcd110d7086c2d854642c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
