CVE-2026-6238

What it actually does

GNU C Library versions 2.0.1 through 2.43 contain an out-of-bounds read / improper length validation issue in deprecated DNS debugging functions: ns_printrrf, ns_printrr, and fp_nquery. When these functions format DNS responses containing A6, CERT, LOC, TKEY, or TSIG records, they do not fully validate that the RDATA content matches the declared RDATA length. A crafted DNS response can therefore cause an application that calls these deprecated interfaces to crash or disclose uninitialized process memory. The flaw is not in the normal glibc DNS resolver path, so applications using standard hostname resolution are not directly exposed unless they explicitly use these deprecated debugging/printing functions.

Why it matters to the business

The likely impact is limited but still operationally relevant: affected applications that parse and print DNS responses using these deprecated glibc interfaces could be remotely crashed or could unintentionally expose small amounts of process memory. Because glibc is widely distributed across Linux systems, the vulnerable code may be present on many hosts, but exploitability depends on whether an application actually calls the deprecated functions. The CVSS score is moderate, EPSS is currently low, it is not listed in CISA KEV, and there is no known ransomware association, so prioritization should focus on internet-facing or security-sensitive software that performs DNS packet inspection, troubleshooting, monitoring, logging, or diagnostic output through these interfaces.

How an attack unfolds

An attacker positions themselves to provide or influence a DNS response consumed by a target application, such as by operating an authoritative DNS server for a queried domain, intercepting DNS traffic, poisoning an upstream resolver, or otherwise controlling DNS packet input to a diagnostic or DNS-processing tool. The attacker crafts a DNS response containing one of the affected record types, such as A6, CERT, LOC, TKEY, or TSIG, with RDATA fields that are inconsistent with the declared RDATA length. If the target application passes that response to ns_printrrf, ns_printrr, or fp_nquery for formatted output, glibc may read beyond the validated RDATA boundary. Depending on process state and memory layout, the result may be an application crash or unintended inclusion of uninitialized memory in output, logs, terminal output, or diagnostic artifacts. Standard resolver calls are not the vulnerable execution path; the risk is concentrated in applications that still use these deprecated debugging APIs.

How to fix it

Upgrade glibc when the operating system vendor releases a patched package for this issue. No universal upstream fixed version was provided in the input, so use distribution-specific security advisories and package repositories to determine the corrected glibc build. In parallel, application maintainers should remove use of ns_printrrf, ns_printrr, and fp_nquery because these interfaces are deprecated and intended only for debugging. Replace them with actively maintained DNS parsing/formatting libraries that strictly validate DNS record lengths before rendering. Where immediate upgrade is not possible, reduce exposure by preventing untrusted DNS packets from reaching applications that invoke these functions, disabling diagnostic DNS response printing for untrusted input, filtering malformed DNS responses at network boundaries where feasible, and running affected tools with least privilege and crash isolation.

How to confirm the fix worked

Confirm exposure by checking installed glibc versions and determining whether they fall within versions 2.0.1 through 2.43. Then perform code and binary usage review for references to ns_printrrf, ns_printrr, and fp_nquery in internally developed software, packaged utilities, DNS troubleshooting tools, monitoring agents, and appliances. After remediation, verify that the vendor glibc package includes the security fix or that affected applications no longer link to or call the deprecated functions. Use static analysis, symbol searches, package changelogs, and regression tests with malformed A6, CERT, LOC, TKEY, and TSIG DNS records to confirm the vulnerable code path is no longer reachable or no longer crashes. Monitor application logs and crash reports after deployment to ensure no recurring DNS parsing crashes remain.

Typical attack path

1. Identify an application or tool that uses deprecated glibc DNS response printing functions such as ns_printrrf, ns_printrr, or fp_nquery.
2. Cause the target application to query or process attacker-controlled DNS data.
3. Return a crafted DNS response containing A6, CERT, LOC, TKEY, or TSIG records with malformed or inconsistent RDATA length/content.
4. Trigger the application to format or log the DNS response using the vulnerable glibc function.
5. Cause a denial of service through process crash or attempt to expose uninitialized process memory through output, logs, or crash artifacts.

How to detect it

To assess whether this was already exploited, focus on applications that parse, print, log, or troubleshoot raw DNS responses rather than ordinary hostname lookup activity. Review application logs, system journals, crash reporters, and core dump indexes for crashes occurring immediately after DNS response processing, especially where records of type A6, CERT, LOC, TKEY, or TSIG appear. Inspect logs for malformed DNS packet errors, unexpected diagnostic output containing binary-looking data, or repeated crashes triggered by queries to unusual domains controlled by external parties. On Linux systems, check systemd-coredump, apport, ABRT, container runtime logs, and application-specific crash directories for faults in or near glibc DNS printing functions. For network telemetry, look for unusual or repeated DNS responses containing affected record types from untrusted servers, especially if followed by process termination events. Because exploitation may only cause a crash or transient memory disclosure in output, absence of a durable file artifact does not rule out attempted exploitation.

• ns_printrrf
• ns_printrr
• fp_nquery
• A6 record
• CERT record
• LOC record
• TKEY record
• TSIG record
• systemd-coredump
• Process dumped core
• segmentation fault
• Segmentation fault
• core dumped
• glibc
• libc.so.6
• RDATA length
• malformed DNS
• malformed DNS response
• DNS response parse error
• type A6
• type CERT
• type LOC
• type TKEY
• type TSIG

What your security team should do

• Inventory Linux systems and containers for glibc versions 2.0.1 through 2.43, prioritizing internet-facing, DNS-facing, monitoring, security, and diagnostic systems.
• Search source code, statically linked binaries, and runtime symbol usage for ns_printrrf, ns_printrr, and fp_nquery.
• Apply distribution-provided glibc updates as they become available, prioritizing systems running applications that process untrusted DNS responses.
• Ask application teams to remove deprecated glibc DNS debugging interfaces and migrate to maintained DNS parsing libraries with strict bounds checking.
• Restrict exposure of DNS diagnostic tools and services that process attacker-controlled DNS packets, especially across trust boundaries.
• Review crash telemetry, core dumps, and logs for DNS-related failures involving A6, CERT, LOC, TKEY, or TSIG records.
• Because there is no KEV listing, no known ransomware use, no public exploit maturity, and low EPSS at this time, treat this as targeted hygiene unless local usage of the vulnerable APIs is confirmed.