linux-kernel - [tip: x86/urgent] x86/mm: Fix overflow in __cpa

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>] [day] [month] [year] [list]

Message-ID: <176038922777.709179.9638250242820548802.tip-bot2@tip-bot2>
Date: Mon, 13 Oct 2025 21:00:27 -0000
From: "tip-bot2 for Rik van Riel" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: syzbot+afec6555eef563c66c97@...kaller.appspotmail.com,
 Rik van Riel <riel@...riel.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
 Kiryl Shutsemau <kas@...nel.org>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Subject: [tip: x86/urgent] x86/mm: Fix overflow in __cpa_addr()

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     f25785f9b088ed65089dd0d0034da52858417839
Gitweb:        https://git.kernel.org/tip/f25785f9b088ed65089dd0d0034da52858417839
Author:        Rik van Riel <riel@...riel.com>
AuthorDate:    Sun, 05 Oct 2025 23:48:05 -04:00
Committer:     Dave Hansen <dave.hansen@...ux.intel.com>
CommitterDate: Mon, 13 Oct 2025 13:55:48 -07:00

x86/mm: Fix overflow in __cpa_addr()

The change to have cpa_flush() call flush_kernel_pages() introduced
a bug where __cpa_addr() can access an address one larger than the
largest one in the cpa->pages array.

KASAN reports the issue like this:

BUG: KASAN: slab-out-of-bounds in __cpa_addr arch/x86/mm/pat/set_memory.c:309 [inline]
BUG: KASAN: slab-out-of-bounds in __cpa_addr+0x1d3/0x220 arch/x86/mm/pat/set_memory.c:306
Read of size 8 at addr ffff88801f75e8f8 by task syz.0.17/5978

This bug could cause cpa_flush() to not properly flush memory,
which somehow never showed any symptoms in my tests, possibly
because cpa_flush() is called so rarely, but could potentially
cause issues for other people.

Fix the issue by directly calculating the flush end address
from the start address.

Fixes: 86e6815b316e ("x86/mm: Change cpa_flush() to call flush_kernel_range() directly")
Reported-by: syzbot+afec6555eef563c66c97@...kaller.appspotmail.com
Signed-off-by: Rik van Riel <riel@...riel.com>
Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Reviewed-by: Kiryl Shutsemau <kas@...nel.org>
Link: https://lore.kernel.org/all/68e2ff90.050a0220.2c17c1.0038.GAE@google.com/
---
 arch/x86/mm/pat/set_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index d2d54b8..9709818 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -446,7 +446,7 @@ static void cpa_flush(struct cpa_data *cpa, int cache)
 	}
 
 	start = fix_addr(__cpa_addr(cpa, 0));
-	end =   fix_addr(__cpa_addr(cpa, cpa->numpages));
+	end =   start + cpa->numpages * PAGE_SIZE;
 	if (cpa->force_flush_all)
 		end = TLB_FLUSH_ALL;