From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3475 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Use of size_t and ssize_t in mseek Date: Thu, 27 Jun 2013 12:47:05 -0400 Message-ID: <20130627164705.GA29800@brightrain.aerifal.cx> References: <51CBB6E1.6080302@nicta.com.au> <20130627041028.GV29800@brightrain.aerifal.cx> <51CBBC8F.5050301@nicta.com.au> <20130627042314.GW29800@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1372352124 4637 80.91.229.3 (27 Jun 2013 16:55:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 16:55:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3479-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 27 18:55:25 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UsFTe-0007OS-SY for gllmg-musl@plane.gmane.org; Thu, 27 Jun 2013 18:55:23 +0200 Original-Received: (qmail 30275 invoked by uid 550); 27 Jun 2013 16:55:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30264 invoked from network); 27 Jun 2013 16:55:21 -0000 Content-Disposition: inline In-Reply-To: <20130627042314.GW29800@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3475 Archived-At: 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