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

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



* Aurelien Jarno:

> 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.

Correct, the version Carlos posted does not have the compensation I
added for that, sorry.  I added this after the call to res_init in
resolv_redirect:

  /* Debian's local-dynamic-resolvconf.diff breaks name server
     overrides by application code.  The following triggers lazy
     initialization of the /etc/resolv.conf mtime value because
     res_mkquery calls __res_maybe_init internally.  Subsequent calls
     to this function will not try reload /etc/resolv.conf as a
     result.  */
  {
    unsigned char query[512];
    if (res_mkquery (QUERY, "query.example", C_IN, T_A,
                     NULL, 0, NULL,
                     query, sizeof (query)) < 0)
      {
        printf ("error: res_mkquery: %m\n");
        abort ();
      }
  }


> 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.

This report <https://bugzilla.redhat.com/show_bug.cgi?id=1309665>
is about an incomplete chroot update.  See comment 4 in particular
(although I wrote it without access to the actual installation).


Reply to: