linux-kernel - Re: [PATCH] x86/mm: Limit INVLPGB to VA in invlpgb_flush_addr

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: <c92a1f85eae86b49916ee1d0a8b3214962b18c4f.camel@surriel.com>
Date: Tue, 27 May 2025 19:39:56 -0400
From: Rik van Riel <riel@...riel.com>
To: Jann Horn <jannh@...gle.com>, Borislav Petkov <bp@...en8.de>, Ingo
 Molnar	 <mingo@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Andy
 Lutomirski	 <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/mm: Limit INVLPGB to VA in
 invlpgb_flush_addr_nosync()

On Tue, 2025-05-27 at 23:56 +0200, Jann Horn wrote:
> The intent of invlpgb_flush_addr_nosync() is to flush a specific
> virtual
> address range, but INVLPGB_FLAG_VA is not set.
> If I understand AMD's documentation correctly, this means this will
> flush
> the entire TLB (except entries for guest ASIDs).
> That's safe, but seems like an unintentionally broad flush.
> Fix it by setting INVLPGB_FLAG_VA.
> 
> Fixes: b7aa05cbdc52 ("x86/mm: Add INVLPGB support code")
> Signed-off-by: Jann Horn <jannh@...gle.com>

Reviewed-by: Rik van Riel <riel@...riel.com>

> ---
> I am not entirely sure about this; Rik, can you confirm if this was
> an
> oversight, or if there's actually a reason for not passing
> INVLPGB_FLAG_VA here?

This was totally an oversight, and probably lost
in one of many rounds of cleanups.

Good catch!

-- 
All Rights Reversed.