Bug #94384 Memory leak in TCP_socket::get_listener_socket()
Submitted: 18 Feb 2019 16:18 Modified: 13 Jul 2019 13:57
Reporter: Alexey Kopytov Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Connection Handling Severity:S3 (Non-critical)
Version:5.7, 8.0 OS:Any
Assigned to: CPU Architecture:Any

[18 Feb 2019 16:18] Alexey Kopytov
Description:
Both 5.7 and 8.0 contain the following code in
TCP_socket::get_listener_socket() (omitting unrelated lines):

---
      if (!getaddrinfo(ipv6_all_addresses, port_buf, &hints, &ai)) {
        /*
          IPv6 might be available (the system might be able to resolve an IPv6
          address, but not be able to create an IPv6-socket). Try to create a
          dummy IPv6-socket. Do not instrument that socket by P_S.
        */
        ...
      }
      if (ipv6_available) {
        ...
      } else {
        ... 

        if (getaddrinfo(ipv4_all_addresses, port_buf, &hints, &ai)) {
          ...
        }
     }
---

After the first successful call to getaddrinfo(), ai contains a pointer
to a data structure allocated by the C library. That memory must be
freed with freeaddrinfo().

However, if ipv6_available == false (i.e. under circumstances described
in the comment), we do another call to getaddrinfo() overwriting the
previously returned pointer stored in ai without calling freeaddrinfo()
on it and thus, leaking allocated memory.

How to repeat:
Code analysis in 
sql/conn_handler/socket_connection.cc:TCP_socket::get_listener_socket().
[19 Feb 2019 9:44] MySQL Verification Team
Hello Alexey,

Thank you for the report and feedback.
Verifying based on my internal discussion with the developer.

regards,
Umesh
[13 Jul 2019 13:57] Paul DuBois
Posted by developer:
 
Fixed in 8.0.18.

On systems with working IPv6 address resolution, IPv6 socket creation
failure at connect time resulted in a memory leak.