linux-kernel - Re: [PATCH] irqchip: gic-v3-its: avoid truncating memory addresses

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

Message-ID: <865x8wd5v9.wl-maz@kernel.org>
Date: Tue, 20 Jan 2026 08:51:22 +0000
From: Marc Zyngier <maz@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Arnd Bergmann <arnd@...db.de>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] irqchip: gic-v3-its: avoid truncating memory addresses

On Mon, 19 Jan 2026 20:15:12 +0000,
Arnd Bergmann <arnd@...nel.org> wrote:
> 
> From: Arnd Bergmann <arnd@...db.de>
> 
> On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem
> allocations to be backed by addresses physical memory above the 32-bit
> address limit, as I found while experimenting with larger VMSPLIT
> configurations.
> 
> This caused the qemu virt model to crash in the GICv3 driver, which
> allocates the 'itt' object using GFP_KERNEL. Since all memory below
> the 4GB physical address limit is in ZONE_DMA in this configuration,
> kmalloc defaults to higher addresses for ZONE_NORMAL, and the
> its driver stores the physical address in a 32-bit 'unsigned long'
> variable.
> 
> Change the itt_addr variable to the correct phys_addr_t type instead,
> along with all other variables in this driver that hold a physical
> address.

Ah, nice catch. It's amazing that we've managed for so long with such
a glaring bug. I guess most 32bit VMs don't have much memory above the
4GB limit.

> 
> I checked the gicv5 driver for the same problem, and it correctly
> uses u64 variables,

GICv5 is strictly 64bit, and cannot be plugged on a system that
supports AArch32.

> while all other irqchip drivers don't call
> virt_to_phys or similar interfaces. I expect other drivers to
> have similar issues, but fixing this one is sufficient for
> booting a virtio based guest.
> 
> Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

Cc: stable@...r.kernel.org
Reviewed-by: Marc Zyngier <maz@...nel.org>

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.