From: "Mikko Rapeli" <mikko.rapeli@bmw.de>
To: <steve@sakoman.com>
Cc: <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] CVE's for linux-yocto
Date: Thu, 18 Feb 2021 08:22:37 +0000 [thread overview]
Message-ID: <YC4jyxYG+qaKLZOu@korppu> (raw)
In-Reply-To: <CAOSpxda=kB8f8ddFh0ZV2PeHSWNGVP=zjL0in4EgBSVP3oL6UA@mail.gmail.com>
Hi,
On Tue, Feb 16, 2021 at 08:23:31AM -1000, Steve Sakoman wrote:
> The weekly cve reports for master, gatesgarth, and dunfell currently
> omit linux-yocto since the CPE database for the kernel is notoriously
> incomplete in versioning information.
>
> This morning at the YP technical team meeting we discussed this and
> decided to see if we might, as a team, expend some effort to update
> the CPE database to improve this situation (much as we have been doing
> for the other packages in oe-core)
>
> The first step in this process is to shine some light on the current
> situation, so below is a list of the current CVE hits for linux-yocto
> in all three branches.
Please check https://github.com/nluedtke/linux_kernel_cves
IMO, that information could be moved over to NVD and CPE, but AFAIK the
scripts which generate this git repo with data aren't public.
Another option would be to switch kernel CVE scans to use that git repo
to pull in data from kernel major version and which CVEs are fixed and
unfixed by given minor version release.
That is rather simple to do for anyone who has a bit of time. Though
as recommended by upstream developers, CVEs should never be patched
independently and instead upstream point releases should be merged into
product trees.
For example for dunfell linux-yocto version 5.4.87 and data from
https://github.com/nluedtke/linux_kernel_cves/blob/master/data/5.4/5.4_security.txt
shows that the list of fixed CVEs is between lines 1 and 297 (note
that 5.4.87 point release is missing from the list but previous and following
releases are there, not perfect but that's what it is).
Then the list of unfixed CVEs from newer point releases is:
CVEs fixed in 5.4.88:
CVE-2020-36158: 0a49aaf4df2936bca119ee38fe5a570a7024efdc mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start
CVEs fixed in 5.4.89:
CVE-2020-28374: 485e21729b1e1235e6075318225c09e76b376e81 scsi: target: Fix XCOPY NAA identifier lookup
CVEs fixed in 5.4.92:
CVE-2021-3178: 4aef760c28e8bd1860a27fd78067b4ea77124987 nfsd4: readdirplus shouldn't return parent of export
CVEs fixed in 5.4.94:
CVE-2020-27825: b899d5b2a42a963d6ca7e33d51a35b2eb25f6d10 tracing: Fix race in trace_open and buffer resize call
CVE-2021-3347: 0dae88a92596db9405fd4a341c1915cf7d8fbad4 futex: Ensure the correct return value from futex_lock_pi()
CVEs fixed in 5.4.95:
CVE-2021-3348: 587c6b75d7fdd366ad7dc615471006ce73c03a51 nbd: freeze the queue while we're adding connections
CVEs fixed in 5.4.97:
CVE-2021-20194: 9146fffc5d2a3ec49906daf18d2e983d995b3521 bpf, cgroup: Fix optlen WARN_ON_ONCE toctou
And list of CVEs for which no fix is available in 5.4 branch is the long list of outstanding
(all lines after "Outstanding CVEs") CVEs, some of which do not apply to 5.4 because buggy
code doesn't exist there, or no-one has yet backported the patches etc.
This same process could apply to any kernel major version for which data exists in this
git tree and if the database keeps seeing updates. I've been using this manually to
trigger updates and cross reference which point releases have fixes and I have not
yet found major bugs in the data. Though for updates, like I said, full merge or rebase
of the upstream kernel.org point releases must be done, as also Greg K-H. says.
Cheers,
-Mikko
prev parent reply other threads:[~2021-02-18 8:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-16 18:23 CVE's for linux-yocto Steve Sakoman
2021-02-16 19:02 ` [OE-core] " akuster
2021-02-16 19:49 ` Steve Sakoman
2021-02-18 8:22 ` Mikko Rapeli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YC4jyxYG+qaKLZOu@korppu \
--to=mikko.rapeli@bmw.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=steve@sakoman.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox