All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Barker <paul@pbarker.dev>
To: Junjie Cao <junjie.cao@linux.dev>,
	 openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH v3 6/9] cve-exclusions: set status for CVE-2022-4543
Date: Sun, 16 Aug 2026 17:00:38 +0100	[thread overview]
Message-ID: <4f7e2108248055e7ff9d8eb82086d745ee20fdea.camel@pbarker.dev> (raw)
In-Reply-To: <20260812072842.1176341-7-junjie.cao@linux.dev>

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> 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
> PTEs. The mapping 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 well 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 PTEs. This is an unfixed issue, not a stated
> wontfix - Debian notes "Ignored upstream and KASLR is not expected to be
> resistant to local attacks", Ubuntu has it deferred since 2023-01-10:
> 
>   https://security-tracker.debian.org/tracker/CVE-2022-4543
>   https://ubuntu.com/security/CVE-2022-4543
> 
> 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area", v6.2) randomizes
> the separate cpu_entry_area; it predates this disclosure and does not
> change the offset of entry_SYSCALL_64 from the KASLR base.

There's too much unnecessary detail here. Drop the mention of a commit
that doesn't fix the issue, you don't need to say "not a stated
wontfix", etc.

> 
> CC: Paul Barker <paul@pbarker.dev>
> AI-Generated: Uses Claude (claude-opus-5)
> Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
> ---
> v3:
> - use "unpatched" instead of "upstream-wontfix": the security-team
>   discussion produced no clear wontfix decision
> 
> v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/
> 
>  meta/recipes-kernel/linux/cve-exclusion.inc | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
> index b08eaa1..a909aef 100644
> --- a/meta/recipes-kernel/linux/cve-exclusion.inc
> +++ b/meta/recipes-kernel/linux/cve-exclusion.inc
> @@ -229,3 +229,11 @@ was never substantiated and was closed as not-a-bug by Red Hat, SUSE and Debian"
>  # 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"
> +
> +# "EntryBleed": KPTI maps the entry text into the user page tables with
> +# the global bit set, leaking the KASLR base by prefetch timing. Discussed
> +# with the kernel security team; no fix, KASLR is not treated as a boundary
> +# against local attackers. Distinct from CVE-2023-3640 (cpu_entry_area).
> +# https://www.willsroot.io/2022/12/entrybleed.html
> +CVE_STATUS[CVE-2022-4543] = "unpatched: no upstream fix, KASLR is not \
> +treated as a defence against local attackers"

Suggested wording, links and include triage date:

    # 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"

Best regards,

-- 
Paul Barker



  reply	other threads:[~2026-08-16 16:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12  7:28 [OE-core][PATCH v3 0/9] cve-exclusions: triage nine kernel CVEs lacking upstream fix data Junjie Cao
2026-08-12  7:28 ` [OE-core][PATCH v3 1/9] cve-exclusions: set status for CVE-2019-14899 Junjie Cao
2026-08-16 15:50   ` Paul Barker
2026-08-12  7:28 ` [OE-core][PATCH v3 2/9] cve-exclusions: set status for CVE-2021-3714 Junjie Cao
2026-08-16 15:53   ` Paul Barker
2026-08-12  7:28 ` [OE-core][PATCH v3 3/9] cve-exclusions: set status for CVE-2021-3864 Junjie Cao
2026-08-16 15:55   ` Paul Barker
2026-08-12  7:28 ` [OE-core][PATCH v3 4/9] cve-exclusions: set status for CVE-2022-0400 Junjie Cao
2026-08-16 16:35   ` Paul Barker
2026-08-12  7:28 ` [OE-core][PATCH v3 5/9] cve-exclusions: set status for CVE-2022-1247 Junjie Cao
2026-08-16 16:21   ` Paul Barker
2026-08-12  7:28 ` [OE-core][PATCH v3 6/9] cve-exclusions: set status for CVE-2022-4543 Junjie Cao
2026-08-16 16:00   ` Paul Barker [this message]
2026-08-12  7:28 ` [OE-core][PATCH v3 7/9] cve-exclusions: set status for CVE-2023-3397 Junjie Cao
2026-08-16 16:05   ` Paul Barker
2026-08-12  7:28 ` [OE-core][PATCH v3 8/9] cve-exclusions: set status for CVE-2023-6238 Junjie Cao
2026-08-16 16:11   ` Paul Barker
2026-08-12  7:28 ` [OE-core][PATCH v3 9/9] cve-exclusions: set status for CVE-2023-6240 Junjie Cao
2026-08-16 16:14   ` Paul Barker
2026-08-16 16:39 ` [OE-core][PATCH v3 0/9] cve-exclusions: triage nine kernel CVEs lacking upstream fix data Paul Barker
2026-08-19 10:43   ` Junjie Cao
2026-08-24  4:13     ` 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=4f7e2108248055e7ff9d8eb82086d745ee20fdea.camel@pbarker.dev \
    --to=paul@pbarker.dev \
    --cc=junjie.cao@linux.dev \
    --cc=openembedded-core@lists.openembedded.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 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.