Re: [PATCH man] mmap.2: Document danger of mappings larger than PTRDIFF_MAX

[Jann Horn <jannh@google.com>]

On Wed, Apr 9, 2025 at 10:41 PM Alejandro Colomar <alx@kernel.org> wrote:
> On Wed, Apr 09, 2025 at 10:03:16PM +0200, Jann Horn wrote:
> > References:
> >  - C99 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
> >    section "6.5.6 Additive operators", paragraph 9
> >  - object size restriction in GCC:
> >    https://gcc.gnu.org/legacy-ml/gcc/2011-08/msg00221.html
> >  - glibc malloc restricts object size to <=PTRDIFF_MAX in
> >    checked_request2size()
> > ---
> > I'm not sure if we can reasonably do anything about this in the kernel,
> > given that the kernel does not really have any idea of what userspace
> > object sizes look like,
>
> Hmmm.  Maybe it could reject PTRDIFF_MAX within the kernel, which would
> at least work for cases where user-space ptrdiff_t matches the kernel's
> ptrdiff_t?  Then only users where they don't match would be unprotected,
> but those are hopefully extra careful.

Perhaps. But then some tricky things are:

1. How many existing users would we be breaking with such a change?
Probably _someone_ out there is deliberately mapping files over 2G
into 32-bit processes and it sorta worked until now...
2. We don't really have a concept of object size in the kernel, and it
might be hard to reason about whether mmap() is used logically to
create a new object or extend an existing object. I guess we could
limit VMA sizes for 32-bit userspace to 0x7ffff000 and enforce a
1-page gap around mappings that are at least half that size, or
something like that, but that would probably get a bit ugly on the
kernel side...

The first point is really the main concern for me - we might end up
breaking existing users.

> > or whether userspace even wants C semantics.
>
> I guess any language will have to link to C at some point, or have
> inherent limitations similar to those of C.

This limitation is really a result of deciding to make pointer
subtraction return a signed value, so that you can subtract a bigger
pointer from a smaller pointer. I don't know whether other languages
do that.

> > But we can at least document it...
>
> Yep.  Most people are unaware of this, and believe they can get
> SIZE_MAX.
>
> >
> > @man-pages maintainer: Please wait a few days before applying this;
> > I imagine there might be some discussion about this.
>
> Okay; see some minor comments below.

Thanks. (I'll probably be out for the next two weeks or so, I'll
probably get back to this afterwards.)