From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112945 invoked by alias); 10 Apr 2018 15:31:39 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 112693 invoked by uid 89); 10 Apr 2018 15:31:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=interior, 2gb, 2GB X-HELO: smtp.ispras.ru Date: Tue, 10 Apr 2018 15:31:00 -0000 From: Alexander Monakov To: Paul Pluzhnikov cc: Andreas Schwab , GLIBC Devel Subject: Re: [patch] Fix path length overflow in realpath (BZ#22786) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2018-04/txt/msg00189.txt.bz2 On Tue, 10 Apr 2018, Paul Pluzhnikov wrote: > On Tue, Apr 10, 2018 at 1:08 AM Andreas Schwab wrote: > > > Trying to allocate a block of INT_MAX+1 is rather likely to fail on a > > 32-bit platform. > > But that's the only way to test for this overflow AFAICT. > > Should I submit the fix without the test? > Should I submit the fix and the test, but disabled? Don't know for the above, but for this question: > Should I change the test to pass if allocation fails? I believe returning EXIT_UNSUPPORTED would be reasonable. Note that the testcase requires not only 2GB of address space, but also causes faults and allocation for the whole range while doing the memset; that sounds like a fairly heavy requirement. Personally I'd rather avoid that by mmap'ing the buffer with MAP_NORESERVE, initializing its head/tail as appropriate, and duplicating the "aaaa..." in the middle by mmapping over pages in the interior with MAP_FIXED. Alexander