Re: [PATCH v1] kasan: Fix false-positive wild-memory-access on x86 under 5-level paging

[Borislav Petkov]

On Thu, Jun 18, 2026 at 11:12:09AM -0700, Dave Hansen wrote:
> 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@xxxxxxxxxxxxx
> 
> 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?

early_ is only on the BSP and you want to scan all CPUs.

AFAIR, the last time I was looking at how we scan the CPUID leafs, we do have
cases where there's blips in time when cap bits get disappeared to be
rescanned again. The toggling of MSR bits which control feature flags is one
thing that comes to mind.

But I'm with you on the consolidation approach. I think this is what we should
do here and then that will be converted to the new way once Ahmed's lands.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette