[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#815974: Segmentation fault in libresolv triggered by php5-fpm



On 2016-02-26 13:31, Carlos O'Donell wrote:
> On Fri, Feb 26, 2016 at 7:46 AM, Fabian Niepelt <F.Niepelt@mittwald.de> wrote:
> > This is the correct output, the older one contains a test I thought was
> > in an endless loop but succeeded after a few minutes.
> 
> The glibc maintainers for debian need to review those failures. They
> indicate serious deviation from expected behaviour. At the very least
> the bug 18665* tests should not fail. However, the tests are sensitive
> to response order.
> 
> -address: STREAM/TCP 10.0.3.6 80
> -address: STREAM/TCP 2001:db8::4:6 80
> +error: Name or service not known
> 
> This is a weird failure.

The failures in this testsuite do not pass due to the patch we have that
dynamically reloads /etc/resolv.conf when it changes. Just after the
fake servers have been initialized, our libc reloads the configuration
from /etc/resolv.conf, and thus the tests fail. Once removing the
corresponding patch the tests pass, at least on my system.

Anyway I don't think it's related to the problem reported here. The
problem lies in the backport of the following patch, which is a
prerequisite for fixing CVE-2015-7547.

  commit ab09bf616ad527b249aca5f2a4956fd526f0712f
  Author: Andreas Schwab <schwab@suse.de>
  Date:   Tue Feb 18 10:57:25 2014 +0100

      Properly fix memory leak in _nss_dns_gethostbyname4_r with big DNS answer
    
      Instead of trying to guess whether the second buffer needs to be freed
      set a flag at the place it is allocated

This patch changes the ABI of the __libc_res_nsearch function, adding
the ansp2_malloced argument. When this function is called by
_nss_dns_gethostbyname4_r  from a libc without the patch (ie the one
installed before applying the security fix), the argument contains
random values, leading to a segfault.

IMHO making sure that programs are restarted after applying the security
update should be enough, but I am not fully sure about my analysis, so a
confirmation would be nice to have.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: