glibc 2.37 separates address lookup from local configuration

A hostname lookup can omit an address family because of the machine performing the lookup. That distinction matters when a diagnostic command appears to disagree with the records an administrator expects. glibc 2.37 adds a way to ask its getent tool for results without the address-configuration filter, making one source of that disagreement explicit.

Carlos O'Donell's February 2 release announcement names --no-addrconfig as the major new feature. The release also removes legacy dynamic-loader search behavior and fixes a memory disclosure in syslog. Taken together, these changes concern how existing programs interact with the surrounding system. They do not require a new C language construct.

Much of C's importance to me lies in the interfaces between independently built parts of a system. The runtime belongs in that assessment because source-level familiarity says little about which shared object a loader selects or why a name lookup returns a particular family. This release makes the lookup policy easier to inspect and retires some old library-selection behavior.

What the new option changes

The release announcement says getent --no-addrconfig can return addresses from families that are not configured on the current host. It describes the behavior as omitting AI_ADDRCONFIG from the getaddrinfo call. The flag therefore affects the policy used for resolving a name, which is distinct from the contents of the name service itself.

The 2.37 getent implementation makes the mechanism visible. A variable named addrconfig_flags initially contains AI_ADDRCONFIG. The lookup code includes that variable in the flags passed through its hints structure. Selecting the new option sets the variable to zero.

That implementation detail constrains what the command promises. The option removes this particular filter. It does not assert that an address is reachable, change the host's network interfaces, or install a route. A returned address and a usable connection remain different observations. The useful diagnostic question is whether local address-family configuration explains a difference in lookup results.

For a name relevant to the system being investigated, the two forms can be compared directly:

getent ahosts example.com
getent --no-addrconfig ahosts example.com

The command uses the new option in its long form so the policy change remains visible. No particular output is promised here. The name-service configuration and the machine's state determine the results, and the point of the comparison is to vary the address-configuration flag while keeping the name and lookup tool the same.

A difference between the outputs supplies a more precise lead than treating every missing address as a DNS publication failure. Conversely, identical output does not prove that the network is correctly configured. The option answers a bounded question about the resolver request. That makes it useful in an investigation without turning it into a general connectivity test.

I value diagnostic options that expose a library's actual input policy. A tool becomes easier to interpret when an administrator can disable one filter explicitly and compare the result. It also makes a report more reproducible because the command line records whether that policy was active.

The loader removes an older selection mechanism

The compatibility change concerns the dynamic linker. According to the announcement, it no longer loads shared objects from tls subdirectories on the library search path, from the subdirectory corresponding to AT_PLATFORM, or through the legacy AT_HWCAP search mechanism. That mechanism had been deprecated in glibc 2.33.

The consequence depends on library placement. A package that relies on one of these special subdirectories cannot assume the new loader will continue selecting the same file through the removed rule. The program's source can remain unchanged while the runtime's choice of library changes. This is why packaging behavior belongs in an assessment of C runtime compatibility.

The wording also needs care. Removal of a legacy mechanism does not establish that all hardware-dependent library selection has disappeared. The 2.37 loader source still passes glibc hardware-capability configuration to its capability-handling code. The release note identifies specific old searches, and its scope should remain that specific.

There is a maintenance tradeoff in retaining every historical lookup convention. Each additional search rule becomes part of the environment that package authors may depend on. Removing deprecated rules reduces that set of conventions, but any deployment using those rules must account for the change in where the loader looks. Backward compatibility here involves the installed filesystem layout as well as exported function names.

This is a useful example of why a runtime release can matter even when its list of new interfaces is short. A C program depends on behavior before its own application logic starts. An old optimized-library directory can therefore be more relevant to an upgrade than an unused new function.

The syslog fix concerns information leaving memory

The announcement identifies CVE-2022-39046 as a security-related change. It describes a crafted input string larger than 1024 bytes causing syslog to read uninitialized heap memory and print it to the target log file. The possible disclosure is therefore through logging output.

The distinction between the application's intended message and the bytes actually emitted is central. A log file is an output destination, and memory copied into it can become visible to readers who were never intended to receive those bytes. The announcement does not need a new network-facing API for this to be a security problem.

Its bug list associates the correction with issue 29536, concerning creation of large syslog messages. The same list also includes issue 29544, a regression involving extra whitespace in syslog calls. These are separate entries, and the whitespace issue should not be confused with the disclosure merely because both affect logging.

The release announcement encourages distributions to follow the release branches corresponding to the versions they ship, where conservative fixes retain backward compatibility. That advice matters when interpreting version numbers operationally. The announcement establishes what the upstream release contains, while a distributor's package history determines which fixes are present in that distributor's runtime.

For me, the syslog correction reinforces a practical limit of reasoning from the small size of the C language. A call with a familiar signature still depends on buffer management inside the library. In 2.37, the documented correction prevents a large crafted message from causing unrelated heap contents to become part of the log output. That is a concrete runtime change for software whose own source does not change at all.