From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14016 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: freeaddrinfo() behavior change in 1.1.21: crash on NULL Date: Tue, 26 Mar 2019 11:11:32 -0400 Message-ID: <20190326151132.GA23599@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="138047"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14032-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 26 16:11:53 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1h8njy-000ZhL-1p for gllmg-musl@m.gmane.org; Tue, 26 Mar 2019 16:11:50 +0100 Original-Received: (qmail 5446 invoked by uid 550); 26 Mar 2019 15:11:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5419 invoked from network); 26 Mar 2019 15:11:44 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14016 Archived-At: On Tue, Mar 26, 2019 at 08:13:40PM +0800, 周欣潼 wrote: > Hi, > > > We were testing connman with musl 1.1.21and hit this issue. The > behavior change was introduced in > http://git.musl-libc.org/cgit/musl/commit/?id=d1395c43c019aec6b855cf3c656bf47c8a719e7f. > Before the change, freeaddrinfo() accepts NULL since it just calls > free(). Now it expects the input pointer to be valid. > > > I am writing to check whether this is expected. connman calls > freeaddrinfo() regard less of the return code of getaddrinfo() and > crashes when getaddrinfo() fails. The document of freeaddrinfo() > does not explicitly state its behavior on NULL, but the wording > seems to indicate the argument should be valid. If this > interpretation is correct, we can proceed to patch connman. This issue has been raised before. My reading is that it's UB to pass a null pointer to freeaddrinfo, but I think there may be room for disagreement on this. The relevant text is: "The freeaddrinfo() function shall free one or more addrinfo ^^^^^^^^^^^ structures returned by getaddrinfo(), along with any additional storage associated with those structures. If the ai_next field of the structure is not null, the entire list of structures shall be freed. The freeaddrinfo() function shall support the freeing of arbitrary sublists of an addrinfo list originally returned by ^^^^^^^^^^^^^^^^^^ getaddrinfo()." "Arbitrary sublists" suggests that the empty sublist might be such a valid sublist, but "one or more" suggests that it's not. I believe a few programs have already been fixed not to pass a null pointer here, but maybe we should consider changing this, or ask the Austin Group for an interpretation. We could also look at the RFC for this interface (from which the POSIX interfaces were ad[ao]pted) and see if it implies that null should be okay. Rich