[Bug nss/34015] New: gethostbyaddr and gethostbyaddr_r return invalid DNS hostnames

carlos at redhat dot com sourceware-bugzilla@sourceware.org
Fri Mar 20 19:20:09 GMT 2026


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

            Bug ID: 34015
           Summary: gethostbyaddr and gethostbyaddr_r return invalid DNS
                    hostnames
           Product: glibc
           Version: 2.43
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nss
          Assignee: unassigned at sourceware dot org
          Reporter: carlos at redhat dot com
  Target Milestone: ---

resolv/nss_dns/dns-host.c (getanswer_ptr):

 855       else if (rr.rtype == T_PTR
 856                && __ns_samebinaryname (rr.rname, expected_name))
 857         {
 858           /* Decompress the target of the PTR record.  This is the
 859              host name we are looking for.  We can only use it if it
 860              is syntactically valid.  Historically, only one host name
 861              is returned here.  If the recursive resolver performs DNS
 862              record rotation, the returned host name is essentially
 863              random, which is why multiple PTR records are rarely
 864              used.  Use MAXHOSTNAMELEN instead of NS_MAXCDNAME for
 865              additional length checking.  */
 866           char hname[MAXHOSTNAMELEN + 1];
 867           if (__ns_name_unpack (c.begin, c.end, rr.rdata,
 868                                 name_buffer, sizeof (name_buffer)) < 0
 869               || !__res_binary_hnok (expected_name)
 870               || __ns_name_ntop (name_buffer, hname, sizeof (hname)) < 0)
 871             {
 872               *h_errnop = NO_RECOVERY;
 873               return NSS_STATUS_UNAVAIL;
 874             }
 875           /* Successful allocation is checked by the caller.  */
 876           *hnamep = alloc_buffer_copy_string (abuf, hname);
 877           return NSS_STATUS_SUCCESS;
 878         }

A defect in the getanswer_ptr function, which implements the iteration and
extraction of the answer from a DNS response, can cause it to accept an invalid
DNS hostname that can contain shell metacharacters. An application that uses
the returned hostname in a shell, without guarding for shell expansion, may be
subject to shell injection attacks.  At the
time of publication, no known affected DNS server returns results with shell
metacharacters in the results.  An attacker would either need to be network
adjacent or have compromised the DNS server to use this defect for shell
injection.  No known vulnerable application has been identified.

The fix is to call __res_binary_hnok(name_buffer) instead of against the
expected_name (which came from the question section).

Reported-by: Antonio Maini (0rbitingZer0) - 0rbitingZer0@proton.me

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


More information about the Glibc-bugs mailing list