From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 9B0AD2890E for ; Tue, 5 Nov 2024 04:01:12 +0100 (CET) Received: (qmail 14151 invoked by uid 550); 5 Nov 2024 03:01:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 14107 invoked from network); 5 Nov 2024 03:01:07 -0000 Date: Mon, 4 Nov 2024 22:00:58 -0500 From: Rich Felker To: "Zhao, Lihua (CN)" Cc: "musl@lists.openwall.com" Message-ID: <20241105030058.GF10433@brightrain.aerifal.cx> References: <20241105010633.1512010-1-lihua.zhao.cn@windriver.com> <20241105014652.GE10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] mman: correct length check in __shm_mapname On Tue, Nov 05, 2024 at 02:03:21AM +0000, Zhao, Lihua (CN) wrote: > This issue is found by attached test case, it works well with glibc. > > sem_name[0] = '/'; > > sem_name[NAME_MAX + 1] = '\0'; > > memset(sem_name + 1, 'N', NAME_MAX); > > /* Create the semaphore */ > sem = sem_open(sem_name, O_CREAT, 0777, 1); > > The above code will generate below string which has one '/' and 255 'N's: > > "/NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN" > > When call __shm_mapname, it firstly try to skip the first '/' > character, name point to the first 'N' character, the p will point > to the EOS, so the p-name equal 255, the original code won't enter > the ENAMETOOLONG branch. The name string should end with EOS, and > all valid characters should be less than or equal to 254. This "should" is incorrect. A name consisting of 255 N's is valid not an error. NAME_MAX is the maximum length of a file name (pathname component) in bytes, not the amount of storage needed for such a string buffer. Reference: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/limits.h.html "{NAME_MAX} Maximum number of bytes in a filename (not including the terminating null of a filename string)." Rich