This cve (https://nvd.nist.gov/vuln/detail/CVE-2022-46176) is a security vulnirability when using cargo ssh.
Kirkstone doesn't support rust on-target images and the bitbake using the 'wget' (which uses 'https') for fetching the sources instead of ssh.
So, cargo-native also not vulnerable to this cve and so added to excluded list.
(From OE-Core rev: 7e4037fd0a66a860b4809be72a89e2de97960a17)
Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@windriver.com>
Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: 94fad58c6f10d0dfc42be816b0a7f6b108bd03e6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 68291026aab2fa6ee1260ca95198dd1d568521e5)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: 726ce5bf1ea64d31f523ec5aff905407480c1095)
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>
(cherry picked from commit 319d465d44328b5f062d2da0526c0e8b189b4239)
Signed-off-by: Steve Sakoman <steve@sakoman.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>
