[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130627164705.GA29800@brightrain.aerifal.cx>
Date: Thu, 27 Jun 2013 12:47:05 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Use of size_t and ssize_t in mseek
On Thu, Jun 27, 2013 at 12:23:14AM -0400, Rich Felker wrote:
> As far as I can tell, mmap and maybe shmat are the only functions that
> might be able to make such large objects. Do you know any others?
It's actually shmget, not shmat, that takes the size argument. I
RTFS'd the kernel a bit, and there's a setting for max shm segment
size that normally caps the size much lower than PTRDIFF_MAX. I also
found an integer overflow in the kernel: if size+PAGE_SIZE-1 overflows
(which is possible if this limit is increased near or to SIZE_MAX),
the size will be accounted as 0 pages, but the full size object will
be created. The impact seems low since it only affects the case where
the administrator has attempted to allow huge individual shm objects
but limit the total shm usage on the system.
In any case, fixing shmget in userspace looks hard since the size
should not be rejected as invalid if the key already exists, only if
it's new. And by default the kernel will catch invalid sizes (and even
mildly large sizes) and reject them, so I don't think any action is
required on musl's part.
I am however preparing a patch for mmap.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
