use-after-free in open_socket_out

Carlos Carvalho carlos at
Tue Jul 12 16:12:39 MDT 2011

This is to ask for a slight enhancement in the new multi-protocol IP
printing. I'm keeping the bug thread because in our machines it
revealed another problem with the code that's already there.

The new feature is indeed very useful but something else is needed:
print the IP of the server even when the connection is successful, and
also print any IPs that were tried but didn't work. These features are
particularly important in the transition to IPv6, where many bugs in
networking and machine configuration appear, and are complicated by
the multiplicity of protocols and addresses.

Printing the IP actually used is very important when the connection
works but the server at the other end is not the expected one, or has
a wrong behavior because the connection came via an unexpected
address/route or client address. One of the many examples of this is
when the dns name points to an organization for v4 but to another
institution for v6, because the v4 one doesn't offer v6 yet. Printing
the IPs that didn't work is important because rather frequently they
should have worked...

These problems become a nightmare when you do many updates every day
spread among tens of different repositories from as many
organizations. Wayne, it'd be really useful here...

The attached path is a suggestion for 3.1; I've hidden it under
--debug=CONNECT3. For 3.0.9 I suggest it for verbose > 2. The patch is
very small because the current versions already almost do it.

Putting it in production showed a bizarre error: the IP produced by
inet_ntop (the line commented out) works for v4 but is wrong for IPv6.
Here's an example:

opening tcp connection to port 873
Connected to ::2001:4f8:8:36:230:48ff

The correct one is 2001:4f8:8:36:230:48ff:fedf:940e. It's wrong for
all v6 addresses that we use, and is correct for all v4 ones. The call
to inet_ntop looks correct; I don't know if this is a problem with our
machines only. Changing to getnameinfo fixed it:

opening tcp connection to port 873
Connected to 2001:4f8:8:36:230:48ff:fedf:940e

It thus seems to be a libc problem (glibc in our case). I tested it
with Debian stable and unstable. Even if it's specific to this case it
may cause portability problems. In the patch I did NOT change the
existing code.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 922 bytes
Desc: not available
URL: <>

More information about the rsync mailing list