From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6062 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: New static analysis results Date: Thu, 4 Sep 2014 13:13:58 -0400 Message-ID: <20140904171357.GB23797@brightrain.aerifal.cx> References: 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 1409850857 8131 80.91.229.3 (4 Sep 2014 17:14:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 17:14:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6075-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 04 19:14:11 2014 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 1XPabr-0004DY-2m for gllmg-musl@plane.gmane.org; Thu, 04 Sep 2014 19:14:11 +0200 Original-Received: (qmail 16376 invoked by uid 550); 4 Sep 2014 17:14:10 -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 16368 invoked from network); 4 Sep 2014 17:14:10 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6062 Archived-At: On Thu, Sep 04, 2014 at 08:45:45PM +0400, Alexander Monakov wrote: > Hello, > > I'm happy to report a few new results from running static code analysis on > musl (from a tool developed where I work). > > ctime.c:5 > localtime(t) may return NULL, but that will cause UB in asctime Yes, I need to look into what ctime should do in this case though... > regexec.c:253 > "return REG_NOMATCH;" in GET_NEXT_WCHAR leaks memory allocated for 'buf' This should be checked, but it sounds likely. > lookup_serv.c:55 > getnameinfo.c:99 > pointless "if (!p) continue;" when "if (!*p) continue;" was probably > intended I'd have to look at the code but it's possible the intent was leftover from old code that was changed rather than being what you think. But I think your proposed change is probably right for the current code. Looks low-priority anyway (only affects parsing invalid hosts/services files). > fpathconf.c > off-by-one error in range check (if (name >= sizeof ...)) Indeed. This should be fixed. Rich