All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junjie Cao <junjie.cao@linux.dev>
To: openembedded-core@lists.openembedded.org
Cc: paul@pbarker.dev
Subject: [OE-core][PATCH v4 5/8] cve-exclusions: set status for CVE-2022-4543
Date: Sun, 23 Aug 2026 23:21:20 -0500	[thread overview]
Message-ID: <20260824042123.1456876-6-junjie.cao@linux.dev> (raw)
In-Reply-To: <20260824042123.1456876-1-junjie.cao@linux.dev>

KPTI clones the kernel entry text into the user page tables at its
KASLR-slid address and, on CPUs with PGE, sets the global bit on those
entries. The translation survives the CR3 write on kernel exit, and a
local attacker can time prefetch instructions across the kernel range
to recover the KASLR base in under a second.

Disclosure and write-up:

  https://www.openwall.com/lists/oss-security/2022/12/16/3
  https://www.willsroot.io/2022/12/entrybleed.html

The disclosure states that after discussion with security@kernel.org
and linux-distros "a fix for this is currently not available", and none
has appeared since; arch/x86/mm/pti.c still clones the entry text and
sets _PAGE_GLOBAL on the cloned mapping. Debian notes "Ignored
upstream and KASLR is not expected to be resistant to local attacks";
Ubuntu has the fix deferred since 2023-01-10:

  https://security-tracker.debian.org/tracker/CVE-2022-4543
  https://ubuntu.com/security/CVE-2022-4543

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- use the review's comment and status wording; drop the cpu_entry_area
  commit reference
- tighten the mechanism wording and the timing claim to match the
  cited sources

v3: https://lore.kernel.org/openembedded-core/20260812072842.1176341-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index a9b4d9a2..4318fc79 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -222,3 +222,12 @@ CVE_STATUS[CVE-2021-3864] = "unpatched: Proposed fixes were not merged upstream"
 # Fix https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
 # Fix https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
 CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
+
+# Triaged August 2026 - "EntryBleed", discussed with the kernel security team
+# but no fix appears to have been published since then. Debian says "Ignored
+# upstream and KASLR is not expected to be resistant to local attacks", fix
+# deferred in Ubuntu.
+# https://www.openwall.com/lists/oss-security/2022/12/16/3
+# https://security-tracker.debian.org/tracker/CVE-2022-4543
+# https://ubuntu.com/security/CVE-2022-4543
+CVE_STATUS[CVE-2022-4543] = "unpatched: No fix has been proposed"
-- 
2.43.0



  parent reply	other threads:[~2026-08-24  2:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24  4:21 [OE-core][PATCH v4 0/8] cve-exclusions: triage eight kernel CVEs lacking upstream fix data Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 1/8] cve-exclusions: set status for CVE-2019-14899 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 2/8] cve-exclusions: set status for CVE-2021-3714 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 3/8] cve-exclusions: set status for CVE-2021-3864 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 4/8] cve-exclusions: set status for CVE-2022-1247 Junjie Cao
2026-08-24  4:21 ` Junjie Cao [this message]
2026-08-24  4:21 ` [OE-core][PATCH v4 6/8] cve-exclusions: set status for CVE-2023-3397 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 7/8] cve-exclusions: set status for CVE-2023-6238 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 8/8] cve-exclusions: set status for CVE-2023-6240 Junjie Cao
2026-08-24  7:57 ` [OE-core][PATCH v4 0/8] cve-exclusions: triage eight kernel CVEs lacking upstream fix data Paul Barker

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=20260824042123.1456876-6-junjie.cao@linux.dev \
    --to=junjie.cao@linux.dev \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@pbarker.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.