From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 23884 invoked from network); 8 May 2020 18:46:13 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 May 2020 18:46:13 -0000 Received: (qmail 14289 invoked by uid 550); 8 May 2020 18:46: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 Received: (qmail 14271 invoked from network); 8 May 2020 18:46:06 -0000 Date: Fri, 8 May 2020 14:45:53 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com, "zhuyan (M)" Message-ID: <20200508184553.GK21576@brightrain.aerifal.cx> References: <20200508143931.5165-1-zhuyan34@huawei.com> <2f7471a2f0ac45f6bfc48191e16b25ec@huawei.com> <20200508154737.GA25182@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200508154737.GA25182@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] fix coredump when sched_rr_get_interval parameter ts is NULL On Fri, May 08, 2020 at 05:47:37PM +0200, Markus Wichmann wrote: > On Fri, May 08, 2020 at 02:46:56PM +0000, zhuyan (M) wrote: > > In function sched_rr_get_interval, there is a risk of null pointer > > reference. On line 12, when ts is NULL, dereferencing the null > > pointer will cause the program coredump. > > > > Therefore, it must ensure that ts is not empty before use. > > > > Is calling this function with a NULL pointer sensible? The manpage > certainly doesn't say so. Usually policy in musl is to not fix > application bugs, but to dereference pointers without NULL pointer check > unless there is an explicit requirement in the relevant standards that a > NULL pointer be accepted. Indeed, sched_rr_get_interval has no contract to accept a null pointer, and doesn't even have a plausible reason to want to call it with one (the only output is in the pointed-to memory). Rich