linux-kernel - Re: [PATCH v3] MIPS: mm: Prevent a TLB shutdown on initial uniquification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2511280646310.36486@angie.orcam.me.uk>
Date: Fri, 28 Nov 2025 07:12:02 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Klara Modin <klarasmodin@...il.com>
cc: Nick Bowler <nbowler@...conx.ca>, 
    Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Jiaxun Yang <jiaxun.yang@...goat.com>, linux-mips@...r.kernel.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] MIPS: mm: Prevent a TLB shutdown on initial
 uniquification

On Fri, 28 Nov 2025, Klara Modin wrote:

> > +/*
> > + * Initialise all TLB entries with unique values that do not clash with
> > + * what we have been handed over and what we'll be using ourselves.
> > + */
> >  static void r4k_tlb_uniquify(void)
> >  {
> > -	int entry = num_wired_entries();
> > +	unsigned long tlb_vpns[1 << MIPS_CONF1_TLBS_SIZE];
> > +	int tlbsize = current_cpu_data.tlbsize;
> > +	int start = num_wired_entries();
> 
> It seems that for my Edgerouter 6P (identifies itself as "CPU0 revision
> is: 000d9602 (Cavium Octeon III)") current_cpu_data.tlbsize is larger
> than 1 << MIPS_CONF1_TLBS_SIZE (256 rather than 64) and
> num_wired_entries() returns 0 so the loop will overwrite part of the
> stack and hangs the system.

 Thank you for the report.  A fix is in review already, please try it: 
<https://lore.kernel.org/r/alpine.DEB.2.21.2511280544050.36486@angie.orcam.me.uk/>.

> Although it boots if I remove the call to r4k_tlb_uniquify(), I have run
> into issues when enabling transparent hugepages and hugetlb in the past
> but not sure if that's related to this, and I still seem to be able to
> trigger that issue sometimes with this patch. Attaching the panic for
> that just in case, though.

 Unrelated.  There's an obvious clash here:

[   23.341961] Index    : 80000000
[   23.345104] PageMask : 1fe000
[   23.348073] EntryHi  : c0000000000c609b
[   23.351911] EntryLo0 : 000000000014afc7
[   23.355749] EntryLo1 : 0000000000000001
[   23.359587] Wired    : 0
[   23.362122] PageGrain: e8000000

-- so this is an attempt to create a TLB entry for a pair of 1MiB pages at 
0xc0000000000c6000 (which is already suspicious as the VPN is obviously 
not 2MiB-aligned, but the extraneous bits will be masked by hardware), and 
it collides with all these entries:

[   25.918311] Index: 193 pgmask=4kb va=c00000000005a000 asid=9b
[   25.918311] 	[ri=0 xi=0 pa=0000593d000 c=0 d=1 v=1 g=1] [ri=0 xi=0 pa=0000593e000 c=0 d=1 v=1 g=1]
[   25.933035] Index: 194 pgmask=4kb va=c000000000072000 asid=9b
[   25.933035] 	[ri=0 xi=0 pa=00005955000 c=0 d=1 v=1 g=1] [ri=0 xi=0 pa=00005956000 c=0 d=1 v=1 g=1]
[   25.947760] Index: 195 pgmask=4kb va=c000000000016000 asid=9b
[   25.947760] 	[ri=0 xi=0 pa=00000000000 c=0 d=0 v=0 g=1] [ri=0 xi=0 pa=00005886000 c=0 d=1 v=1 g=1]
[   25.962483] Index: 196 pgmask=4kb va=c00000000001a000 asid=9b
[   25.962483] 	[ri=0 xi=0 pa=00005888000 c=0 d=1 v=1 g=1] [ri=0 xi=0 pa=00005889000 c=0 d=1 v=1 g=1]

 HTH,

  Maciej