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

[Andrew Morton]

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).

AI review might have found a couple of unrelated pre-existing issues in
the surrounding code:

	https://sashiko.dev/#/patchset/20260630125047.703170-1-yanzhen20011121@xxxxxxx