dbcve.org
Codeready Linux Builder EusApplication · Redhat

CVE-2023-4806

MEDIUM · 5.9 CVSS v3.1 Published 2023-09-18
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
68/100
Remediation priority · Elevated
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
A flaw has been identified in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the _nss_*_gethostbyname2_r and _nss_*_getcanonname_r hooks without implementing the _nss_*_gethostbyname3_r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AF_INET6 address family with AI_CANONNAME, AI_ALL and AI_V4MAPPED as flags.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Use-after-free vulnerability in glibc's getaddrinfo function that occurs when an NSS module implements only the _nss_*_gethostbyname2_r and _nss_*_getcanonname_r hooks but not _nss_*_gethostbyname3_r, combined with getaddrinfo calls using AF_INET6 with AI_CANONNAME, AI_ALL, and AI_V4MAPPED flags for names resolving to many IPv6 and IPv4 addresses.

MitigationUpdate glibc to the patched version, or modify any custom NSS modules to implement the missing _nss_*_gethostbyname3_r hook.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Codeready Linux Builder EusApplication
Affected:= 9.2
Codeready Linux Builder Eus For Power Little EndianApplication
Affected:= 9.0_ppc64le
Codeready Linux Builder Eus For Power Little Endian EusApplication
Affected:= 9.2_ppc64le
Codeready Linux Builder For Arm64Application
Affected:= 9.0_aarch64
Codeready Linux Builder For Arm64 EusApplication
Affected:= 9.2_aarch64
Codeready Linux Builder For Ibm Z SystemsApplication
Affected:= 9.0_s390x
Codeready Linux Builder For Ibm Z Systems EusApplication
Affected:= 9.2_s390x
Enterprise LinuxOperating system
Affected:= 7.0= 8.0= 9.0

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
High
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Check glibc version
    Run `rpm -q glibc` or check the output of `ldd --version` to identify the installed glibc version
    Affected if The glibc version falls within Red Hat Enterprise Linux 7.0, 8.0, 9.0 or the listed Codeready Builder versions for the respective architectures
  2. Identify custom NSS modules
    Examine /etc/nsswitch.conf to see which NSS modules are configured, then check /lib64 or /lib directories for any third-party or custom NSS shared libraries (files matching libnss_*.so*)
    Affected if Any custom NSS module is loaded in addition to or instead of standard system modules like files, dns, or systemd
  3. Check for missing gethostbyname3_r hook
    Inspect the symbols exported by any custom NSS module libraries using `nm -D` or `readelf -s` to see if they define _nss_*_gethostbyname2_r and _nss_*_getcanonname_r but lack _nss_*_gethostbyname3_r
    Affected if The custom NSS module implements gethostbyname2_r and getcanonname_r hooks but does NOT implement the gethostbyname3_r hook
  4. Identify applications using vulnerable getaddrinfo flags
    Review application source code or configuration to determine if any program calls getaddrinfo with AF_INET6 family and includes the flags AI_CANONNAME | AI_ALL | AI_V4MAPPED simultaneously for hostnames resolving to many addresses
    Affected if Any application uses getaddrinfo with all three flags (AI_CANONNAME, AI_ALL, AI_V4MAPPED) for IPv6-capable lookups against a service using a custom NSS module

A system is affected if it runs a vulnerable glibc version AND uses a custom NSS module that implements gethostbyname2_r and getcanonname_r but omits gethostbyname3_r, with any application employing the specific combination of AF_INET6, AI_CANONNAME, AI_ALL, and AI_V4MAPPED flags.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Update glibc to the patched version, or modify any custom NSS modules to implement the missing _nss_*_gethostbyname3_r hook.

Recommended fix Moderate confidence

Update glibc to the latest patched version available via Red Hat errata for your RHEL 7.x, 8.x, or 9.x system

  1. 1. Identify the exact glibc version currently installed: rpm -q glibc
  2. 2. Check for available errata/patches for this CVE in the Red Hat errata database (access.redhat.com) for your specific RHEL version (7.x, 8.x, or 9.x)
  3. 3. Run 'yum update glibc' or 'dnf update glibc' to apply the latest glibc packages containing the security fix
  4. 4. Verify the updated glibc version matches the patched release: rpm -q glibc
  5. 5. Reboot the system to ensure the updated glibc library is loaded for all running processes
  6. 6. Test critical applications that use getaddrinfo to confirm functionality
Caveat Major glibc upgrades may require application recompilation or cause compatibility issues with older binaries; test in staging before production deployment

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Codeready Linux Builder Eus Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing3.0 h
  • Review / QA2.0 h
14.0 hours of engineering $2,490
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,984.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2023-4806 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2023-4806 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data