linux-kernel - Re: [PATCH 5.4.y] iommu/amd: Fix 2G+ memory-size overflow in unmap

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: <2025103008-prideful-trunks-8562@gregkh>
Date: Thu, 30 Oct 2025 12:50:46 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Jinhui Guo <guojinhui.liam@...edance.com>
Cc: stable@...r.kernel.org, joro@...tes.org, linux-kernel@...r.kernel.org,
	iommu@...ts.linux-foundation.org
Subject: Re: [PATCH 5.4.y] iommu/amd: Fix 2G+ memory-size overflow in
 unmap_sg()

On Thu, Oct 30, 2025 at 07:19:56PM +0800, Jinhui Guo wrote:
> Since npages is declared as int, shifting npages << PAGE_SHIFT
> for a 2 GB+ scatter-gather list overflows before reaching
> __unmap_single(), leading to incorrect unmapping.
> 
> A 2 GB region equals 524,288 pages. The expression
> npages << PAGE_SHIFT yields 0x80000000, which exceeds
> INT32_MAX (0x7FFFFFFF). Casting to size_t therefore produces
> 0xFFFFFFFF80000000, an overflow value that breaks the unmap
> size calculation.
> 
> Fix the overflow by casting npages to size_t before the
> PAGE_SHIFT left-shift.
> 
> Fixes: 89736a0ee81d ("Revert "iommu/amd: Remove the leftover of bypass support"")
> Cc: stable@...r.kernel.org # 5.4
> Signed-off-by: Jinhui Guo <guojinhui.liam@...edance.com>
> ---
> 
> Hi,
> 
> We hit an IO_PAGE_FAULT on AMD with 5.4-stable when mapping a
> 2 GB scatter-gather list.
> 
> The fault is caused by an overflow in unmap_sg(): on stable-5.4
> the SG-mmap path was never moved to the IOMMU framework, so the
> bug exists only in this branch.

What upstream commit fixed this?  And why not just backport that?

And as this kernel is only going to be "alive" for one more month (i.e.
probably one more release), why care about it now at all?  Shouldn't you
already have moved your whole infrastructure off of it by now?

Especially because, as of right now, release 5.4.301 contains 1527
unfixed CVEs?  Surely that should mean something? :)

thanks,

greg k-h