linux-kernel - Re: [PATCH v3 22/29] x86/cpu: Use consolidated leaf 0x2 descriptor table

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: <Z-E-vXHVl3dLFYx0@lx-t490>
Date: Mon, 24 Mar 2025 12:15:09 +0100
From: "Ahmed S. Darwish" <darwi@...utronix.de>
To: kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	John Ogness <john.ogness@...utronix.de>, x86@...nel.org,
	x86-cpuid@...ts.linux.dev
Subject: Re: [PATCH v3 22/29] x86/cpu: Use consolidated leaf 0x2 descriptor
 table

Hi,

On Mon, 24 Mar 2025, kernel test robot wrote:
>
> [ 5.001760][ T0] BUG: KASAN: stack-out-of-bounds in intel_detect_tlb (arch/x86/kernel/cpu/intel.c:698 arch/x86/kernel/cpu/intel.c:688)
> [    5.001760][    T0] Read of size 1 at addr ffffffff8a607e80 by task swapper/0/0
> [    5.001760][    T0]
> [    5.001760][    T0] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.14.0-rc5-00152-ge114ca069e27 #1
> [    5.001760][    T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> [    5.001760][    T0] Call Trace:
> [    5.001760][    T0]  <TASK>
> [ 5.001760][ T0] dump_stack_lvl (lib/dump_stack.c:124)
> [ 5.001760][ T0] print_address_description+0x2c/0x3f0
> [ 5.001760][ T0] ? intel_detect_tlb (arch/x86/kernel/cpu/intel.c:698 arch/x86/kernel/cpu/intel.c:688)
>

I've reproduced the KASAN report and below hunk fixes it:

 | --- a/arch/x86/include/asm/cpuid/leaf_0x2_api.h
 | +++ b/arch/x86/include/asm/cpuid/leaf_0x2_api.h
 | @@ -88,9 +88,9 @@ static inline void cpuid_get_leaf_0x2_regs(union leaf_0x2_regs *regs)
 |   *		}
 |   *	}
 |   */
 | -#define for_each_leaf_0x2_entry(regs, __ptr, entry)			\
 | -	for (__ptr = &(regs).desc[1], entry = &cpuid_0x2_table[*__ptr];	\
 | -	     __ptr < &(regs).desc[16];					\
 | -	     __ptr++, entry = &cpuid_0x2_table[*__ptr])
 | +#define for_each_leaf_0x2_entry(regs, __ptr, entry)				\
 | +	for (__ptr = &(regs).desc[1];						\
 | +	     __ptr < &(regs).desc[16] && (entry = &cpuid_0x2_table[*__ptr]);	\
 | +	     __ptr++)

I'll include the fix in v4.

(It also makes sense that this was triggered at x86/cpu intel.c and not
 x86/cacheinfo, since in cacheinfo.c, CPUID(4) when available is always
 preferred to CPUID(2).)

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH