linux-kernel - Re: [PATCH] filemap: avoid truncating 64-bit offset to 32 bits

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: <20250102141015.bc8ef069a91cfd9664538494@linux-foundation.org>
Date: Thu, 2 Jan 2025 14:10:15 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Marco Nelissen <marco.nelissen@...il.com>
Cc: "Matthew Wilcox (Oracle)" <willy@...radead.org>,
 linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: Re: [PATCH] filemap: avoid truncating 64-bit offset to 32 bits

On Thu,  2 Jan 2025 11:04:11 -0800 Marco Nelissen <marco.nelissen@...il.com> wrote:

> on 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a
> 64-bit value to 32 bits, leading to a possible infinite loop when writing
> to an xfs filesystem.
> 
> ...
>
> +++ b/mm/filemap.c
> @@ -3005,7 +3005,7 @@ static inline loff_t folio_seek_hole_data(struct xa_state *xas,
>  		if (ops->is_partially_uptodate(folio, offset, bsz) ==
>  							seek_data)
>  			break;
> -		start = (start + bsz) & ~(bsz - 1);
> +		start = (start + bsz) & ~((u64)bsz - 1);
>  		offset += bsz;
>  	} while (offset < folio_size(folio));
>  unlock:

Thanks.  I'll add

Fixes: 54fa39ac2e00b ("iomap: use mapping_seek_hole_data")
Cc: <stable@...r.kernel.org>

The

	offset = offset_in_folio(folio, start) & ~(bsz - 1);

a few lines earlier is worrisome.  I wonder if we should simply make
`bsz' and `offset' have type u64 and sleep well at night.