[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Feb 2019 13:13:35 -0600
From: Bobby Bingham <koorogi@...rogi.info>
To: musl@...ts.openwall.com
Subject: Re: freeaddrinfo(NULL) segfaults in v1.1.21
On Sun, Feb 03, 2019 at 07:02:38PM +0100, Patrick Steinhardt wrote:
> Hi,
>
> previous to v1.1.21 it was fine to call `freeaddrinfo(NULL)`, as
> the implementation simply called `free(NULL)` in that case. Since
> commit d1395c43 (allow freeaddrinfo of arbitrary sublists of
> addrinfo list, 2018-10-04), this is no longer the case, as musl
> now tries always de-references the passed pointer to free
> potential sublists.
>
> As long as I didn't miss it, freeaddrinfo(3P) doesn't explicitly
> say whether it needs to be called with a valid pointer, and sure
> enough there's applications out there which aren't careful here.
> One example I found is e.g. nfs-utils, where I hit segfaults in
> different places after upgrading to musl v1.1.21.
In general, unless it is specified otherwise, it is undefined behavior
to call functions accepting a pointer with an invalid or NULL pointer.
In this particular case, the spec[1] says:
The freeaddrinfo() function shall free one or more addrinfo
structures returned by getaddrinfo(), along with any additional
storage associated with those structures.
A NULL pointer does not point to "one or more addrinfo structures".
1. http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html
>
> So was this change in behavior intended or is it an unwanted
> side-effect of the commit in question?
I would guess it's an unintended, but not necessarily unwanted, side
effect. When it's easy to detect such application bugs, musl generally
opts to fail loudly at the point of error, so these bugs can be noticed
and fixed by application developers, rather than silently hiding them.
Bobby
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
