Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "Navuduri, Venkata Adhitya" <Venkata.Navuduri@windriver.com>
To: "MacLeod, Randy" <Randy.MacLeod@windriver.com>,
	"yocto@lists.yoctoproject.org" <yocto@lists.yoctoproject.org>,
	"paul@pbarker.dev" <paul@pbarker.dev>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>,
	"linux-yocto@lists.yoctoproject.org"
	<linux-yocto@lists.yoctoproject.org>
Cc: "Korovkin, Dmitriy" <Dmitriy.Korovkin@windriver.com>
Subject: Re: [yocto] linux-yocto CVEs in need of triage
Date: Thu, 23 Jul 2026 12:15:22 +0000	[thread overview]
Message-ID: <1ab8694b-1f76-4059-b0ce-6604bbef3d2f@windriver.com> (raw)
In-Reply-To: <2c3d1180-5390-4a4a-af2b-39f1bc78c385@windriver.com>

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

On 7/22/26 10:45, MacLeod, Randy wrote:
On 2026-06-29 15:33, Paul Barker via lists.yoctoproject.org wrote:

Hi all,

We would appreciate help triaging the following CVEs filed against the
Linux Kernel, which therefore affect linux-yocto.

Each of these is missing an upstream fix version in the CVE data, so
they show as unresolved in our CVE metrics. However, they may well be
fixed already in the kernel versions that we ship. So we need some help
to determine the appropriate upstream fix versions.

For each CVE, at a minimum we need to know if they are resolved in the
mainline kernel, and if so then which release they were resolved in. A
pointer to the exact upstream commit resolving the issue would be
preferred. This may involve a bit of investigation, so please share the
information you find that proves that a CVE is resolved in a particular
kernel version.

Once you've investigated a particular CVE, if it is resolved upstream
then please send a patch to update the linux-yocto cve-exclusion.inc
file with the appropriate information. See recent commits to this file
for examples of what we need, e.g:
    https://git.openembedded.org/openembedded-core/commit/?id=ded28ca69b326e51ac5cf363f06c6f0931a9c1bd

Once we've got patches merged into the master branch, we can look at
backporting to wrynose & scarthgap as appropriate.

The open linux-yocto CVEs lacking an upstream fix version and not
currently tracked in cve-exclusion.inc are:

- CVE-2019-14899
- CVE-2021-3714
- CVE-2021-3864
- CVE-2022-0400
- CVE-2022-1247
- CVE-2022-4543
- CVE-2023-3397
- CVE-2023-3640
- CVE-2023-4010
- CVE-2023-6238
- CVE-2023-6240

Venkata, who goes by Adhitya, has looked into all of these issues.

He's found one CVEs:
   CVE-2023-3640 -  x86 cpu_entry_area KASLR bypass.
that we can backport via linux-stable.

He has notes on the rest of the CVEs and will reply himself shortly.


../Randy


Best regards,










--
# Randy MacLeod
# Wind River Linux

Hello,

Regarding CVE-2023-3640 (x86 cpu_entry_area KASLR bypass, CVSS 7.8):
The mainline fix is commit 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area") by Peter Zijlstra, merged in v6.2-rc1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e3d26b5e5f


So, for Yocto releases shipping kernel >=6.2 version this fix is already present. This fix needs back porting to kernel <6.2

For now, I can prepare a patch to add this CVE in the cve-exclusion.inc to stop the CVE tool from reporting on this.


Best Regards,
Adhitya

[-- Attachment #2: Type: text/html, Size: 3914 bytes --]

  reply	other threads:[~2026-07-23 13:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 19:33 linux-yocto CVEs in need of triage Paul Barker
2026-07-22 14:45 ` [yocto] " Randy MacLeod
2026-07-23 12:15   ` Navuduri, Venkata Adhitya [this message]
2026-07-24 14:18     ` [OE-core] " Paul Barker
2026-08-02 14:33 ` Junjie Cao

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=1ab8694b-1f76-4059-b0ce-6604bbef3d2f@windriver.com \
    --to=venkata.navuduri@windriver.com \
    --cc=Dmitriy.Korovkin@windriver.com \
    --cc=Randy.MacLeod@windriver.com \
    --cc=linux-yocto@lists.yoctoproject.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@pbarker.dev \
    --cc=yocto@lists.yoctoproject.org \
    /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