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: <20250722042431.GAaH8Sf1CuHB1JRgk9@renoirsky.local>
Date: Tue, 22 Jul 2025 06:24:31 +0200
From: Borislav Petkov <bp@...en8.de>
To: Michael Zhivich <mzhivich@...mai.com>
Cc: stable@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	dave.hansen@...ux.intel.com, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/bugs: Fix use of possibly uninit value in
 amd_check_tsa_microcode()

On Mon, Jul 21, 2025 at 07:07:12PM -0400, Michael Zhivich wrote:
> Note: I believe this change only applies to stable backports.

Right, I need to go look in detail which of the 5.10-6.12 stable trees
which got this variant, do have CONFIG_INIT_STACK_NONE.

> For kernels compiled with CONFIG_INIT_STACK_NONE=y, the value of __reserved
> bitfield in zen_patch_rev union on the stack may be garbage.  If so, it will
> prevent correct microcode check when consulting p.ucode_rev, resulting in
> incorrect mitigation selection.

Uuuh, nasty. Good catch.

> Signed-off-by: Michael Zhivich <mzhivich@...mai.com>
> Fixes: 7a0395f6607a ("x86/bugs: Add a Transient Scheduler Attacks mitigation")
> ---
>  arch/x86/kernel/cpu/amd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index efd42ee9d1cc..91b21814ce8c 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -371,7 +371,7 @@ static void bsp_determine_snp(struct cpuinfo_x86 *c)
>  static bool amd_check_tsa_microcode(void)
>  {
>  	struct cpuinfo_x86 *c = &boot_cpu_data;
> -	union zen_patch_rev p;
> +	union zen_patch_rev p = {0};

Instead of doing this...

>  	u32 min_rev = 0;
>  
>  	p.ext_fam	= c->x86 - 0xf;

... you should assign __reserved here to 0 too and put a comment above
it why we're doing that.

This will save us the init writes to 0 which get overwritten with the
actual f/m/s anyway.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ