Re: [PATCH v2] mm: fix mapping_seek_hole_data() overflow on last page

[Jan Kara]

On Wed 01-07-26 17:32:10, Andrew Morton wrote:
> On Tue, 30 Jun 2026 15:27:25 +0200 Jan Kara <jack@xxxxxxx> wrote:
> 
> > On Tue 30-06-26 20:50:47, Zhen Yan wrote:
> > > A local unprivileged process can create a shmem/tmpfs file with
> > > i_size == LLONG_MAX using memfd_create() and fallocate().  If the last
> > > page is present in the page cache, lseek(SEEK_HOLE) on that page
> > > returns 0x8000000000000000 as a successful offset, which is LLONG_MIN
> > > when stored in loff_t.
> > > 
> > > The same file has readable data at the last byte, but SEEK_DATA from
> > > that offset returns ENXIO.
> > > 
> > > The overflow is in mapping_seek_hole_data():
> > > 
> > >   pos = round_up((u64)pos + 1, seek_size);
> > > 
> > > For the final page below LLONG_MAX, the next page boundary is
> > > 0x8000000000000000, which is then used as a signed file offset.
> > > When assigned to the loff_t pos, this overflows to LLONG_MIN, so
> > > a subsequent "pos > end" comparison does not catch it.
> > > 
> > > Keep mapping_seek_hole_data() inside its documented [start, end)
> > > search range: compute round_up() into a u64 variable and compare
> > > against (u64)end so the overflow is detected, then clamp pos to
> > > end when the rounded-up value goes past the search limit.
> > > 
> > > Signed-off-by: Zhen Yan <yanzhen20011121@xxxxxxx>
> > 
> > Thanks for the patch! It looks good. Feel free to add:
> > 
> 
> Thanks.  I'll queue this for 7.3-rc1 with a cc:stable - no rush, as the
> issue is presumably very old.  
> 
> (Do we think the cc:stable is even needed?  It's very obscure and the
> effects aren't very harmful).

Frankly, I don't think it's needed. It isn't like people are using
LLONG_MIN sized files unless they are trying to exploit some bug :)

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR