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.