[Bug network/19573] New: res_nclose and __res_maybe_init disagree about name server initialization, breaking Hesiod

["fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19573

            Bug ID: 19573
           Summary: res_nclose and __res_maybe_init disagree about name
                    server initialization, breaking Hesiod
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
  Target Milestone: ---
             Flags: security-

After commit 2212c1420c92a33b0e0bd9a34938c9814a56c0f7 (Simplify handling of
nameserver configuration in resolver), res_nclose unconditionally frees the
name server list, but __res_maybe_init only initializes it if RES_INIT is not
set in options.

nss_hesiod does this.  It uses _res (hesiod-init.c:_nss_hesiod_init):

  /* Use the default (per-thread) resolver state.  */
  __hesiod_res_set (context, &_res, NULL);

And then calls res_nclose on it (in hesiod.c:hesiod_end):

        if (ctx->res)
                res_nclose(ctx->res);

And again __res_maybe_init (hesiod.c:init):

        if (__res_maybe_init (ctx->res, 0) == -1)
                return (-1);

This causes a crash (null pointer dereference) later in res_nsend.  This is not
a security bug because Hesiod is completely unusable as a result.

The res_n* interfaces are undocumented, and I'm not sure what the expectations
are.  __res_maybe_init is exposed only indirectly.  I'm worried that
applications call res_nclose (&_res) as well, not just Hesiod.  This means that
while we should fix Hesiod to never call res_nclose on &_res, it may make sense
to add a check for this condition to res_nclose as well, for better backwards
compatibility.

-- 
You are receiving this mail because:
You are on the CC list for the bug.