From: Dave Hansen <dave.hansen@intel.com>
To: Borislav Petkov <bp@alien8.de>, Ihor Solodrai <ihor.solodrai@linux.dev>
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
bpf@vger.kernel.org, kasan-dev@googlegroups.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Andrey Konovalov <andreyknvl@gmail.com>
Subject: Re: [PATCH v1] kasan: Fix false-positive wild-memory-access on x86 under 5-level paging
Date: Thu, 18 Jun 2026 11:12:09 -0700 [thread overview]
Message-ID: <3207a706-354c-4e9d-ba53-dded1abb1842@intel.com> (raw)
In-Reply-To: <20260618170913.GBajQmOQyOiBLqopUl@fat_crate.local>
On 6/18/26 10:09, Borislav Petkov wrote:
> On Wed, Jun 17, 2026 at 03:13:33PM -0700, Ihor Solodrai wrote:
>> So my question to maintainers is what approach seems best?
> The CPUID stuff is being rewritten currently and it should address your issue
> too. If not, then we need to rewrite it better.
>
> Can you reproduce with this set applied ontop:
>
> https://lore.kernel.org/r/20260528153923.403473-1-darwi@linutronix.de
Thinking about this a bit more... If Ahmed's series does fix this, I
think it will be accidental. It still uses identify_cpu() and also does
a memset() of the new c->cpuid structure in addition to the old
c->x86_capability structure.
I'm not knocking Ahmed's series by any means. It just probably won't fix
this issue.
In a perfect world early_identify_cpu() and identify_cpu() would either
get consolidated into one thing. Or at least become two discrete things
that initialize two completely disjoint sets of data. That way,
identify_cpu() wouldn't memset() anything.
Isn't that the _real_ fix? Instead of trying to hide the inconsistency
when good data is blown away, we stop blowing it away in the first place?
next prev parent reply other threads:[~2026-06-18 18:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 17:56 [PATCH v1] kasan: Fix false-positive wild-memory-access on x86 under 5-level paging Ihor Solodrai
2026-06-10 18:17 ` sashiko-bot
2026-06-10 18:28 ` Ihor Solodrai
2026-06-10 18:39 ` Andrey Konovalov
2026-06-10 21:55 ` Ihor Solodrai
2026-06-12 16:30 ` Kiryl Shutsemau
2026-06-12 19:42 ` Ihor Solodrai
2026-06-17 22:13 ` Ihor Solodrai
2026-06-18 16:55 ` Andrey Ryabinin
2026-06-18 17:09 ` Borislav Petkov
2026-06-18 18:12 ` Dave Hansen [this message]
2026-06-18 18:38 ` Borislav Petkov
2026-06-23 0:29 ` Ihor Solodrai
2026-06-23 0:35 ` Ihor Solodrai
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=3207a706-354c-4e9d-ba53-dded1abb1842@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=eddyz87@gmail.com \
--cc=hpa@zytor.com \
--cc=ihor.solodrai@linux.dev \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=memxor@gmail.com \
--cc=mingo@redhat.com \
--cc=ryabinin.a.a@gmail.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.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.