Re: [PATCH 5.4.y] iommu/amd: Fix 2G+ memory-size overflow in unmap_sg()

[Greg KH <gregkh@linuxfoundation.org>]

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@vger.kernel.org # 5.4
> Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.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