CVE-2026-3904: Race Condition Crashes in glibc nscd on x86_64

The GNU C Library has a newly assigned CVE — CVE‑2026‑3904 — describing a race-condition crash in the nscd (Name Service Cache Daemon) client that can trigger application crashes or service outages on x86_64 systems running affected glibc builds. Upstream maintainers published a security advisory and fixes on March 11, 2026; NVD and vulnerability vendors have since cataloged the issue and assigned a medium severity rating reflecting the availability-only impact. (openwall.com)

Background / Overview​

The GNU C Library (glibc) implements the core libc runtime used by virtually all Linux distributions and many native applications. One of its subsystems integrates with the system’s Name Service Switch (NSS) framework and the Name Service Cache Daemon (nscd) to accelerate lookups for user, group, host and service information. When NSS-backed functions are invoked with nscd caching enabled, the client-side code path within glibc calls into nscd-related routines. Under certain high-load conditions on x86_64 platforms, an optimized implementation of memcmp introduced in glibc 2.36 (and later backported into the 2.35 branch) can be invoked on memory that is concurrently modified by another thread or process. That undefined concurrent access may cause the optimized memcmp to crash, which in turn crashes the nscd client and any application depending on it. (openwall.com)
This is a classic race condition / undefined-behaviour problem, cataloged under CWE‑366 (race condition within a thread) by the NVD and described in the upstream GLIBC advisory. The issue manifests as denial of service (application/process crash), not as arbitrary code execution or privilege escalation in the upstream advisory and public records. (nvd.nist.gov)

---

What was published (quick facts)​

• Vulnerability: Race condition / crash in nscd client when glibc’s optimized memcmp is used. (nvd.nist.gov)
• Affected versions: glibc 2.36 on x86_64; the optimization was backported to the 2.35 stable branch, making those builds also vulnerable. Distributors that cherry‑picked the memcpy SSE2 optimization into other branches should also verify and apply the upstream fix. (nvd.nist.gov)
• Impact: Local crash / DoS of nscd client (availability impact only). CVSS v3.1 vector published by some assessment sources = AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (Base 6.2 — Medium). EPSS (exploit prediction score) is very low at publication time. (tenable.com)
• Disclosure / advisory sources: upstream glibc advisory (GLIBC‑SA‑2026‑0004), OSS‑security announcement, NVD record; multiple vulnerability intelligence vendors (Tenable, NVD) have posted entries. The Microsoft Security Update Guide page for CVE‑2026‑3904 is registered but requires the vendor’s web UI to be rendered; we relied on upstream and NVD/Tenable records for technical detail. Flag: the MSRC page is present in public tracking but may require JavaScript to view; cross‑checks used upstream and NVD/Tenable instead. (openwall.com)

---

Technical analysis — what really happens​

How memcmp and nscd interact​

The vulnerability arises from the intersection of three facts:

• nscd caches name‑service data returned by NSS providers; the client path in glibc interacts with nscd to avoid repeated synchronous lookups.
• A performance optimization in glibc’s x86_64 memcmp (introduced in 2.36 and later backported) assumes inputs to memcmp are stable for the duration of the call.
• Under high nscd load the nscd client code may call memcmp on buffers that another thread or process can modify concurrently, creating undefined behaviour which, with the optimized memcmp implementation, can lead to a crash. (openwall.com)

In plain terms: a thread‑safety/race issue causes memcmp to be run on data that is not safely immutable at the call site, and the optimized assembly implementation can fault when it observes the memory while it is being changed.

Why this is a DoS and not code execution​

The publicly published advisory and the NVD record emphasize that the result is a crash — an availability impact — rather than memory corruption leading to arbitrary code execution. The optimization’s behavior under the undefined condition triggers a fault/crash rather than predictable, controllable memory corruption exploitable for RCE in the current analysis. That distinction is important: while crashes can be exploited as part of more complex multistage attacks, the immediate severity is disruption rather than unauthorized privilege or code execution. (nvd.nist.gov)

Platform and build nuances​

Only x86_64 builds that include the specific memcmp optimization are implicated. Because many distributions maintain their own glibc builds and sometimes cherry‑pick performance patches, a distribution‑specific glibc build could be vulnerable even if the global upstream versioning looks different. Hence the upstream fix was backported across vulnerable branches, and distributions are expected to ship patched libc packages. (nvd.nist.gov)

---

Who is affected — inventory checklist​

• Any Linux host running glibc built from the vulnerable commit(s) on x86_64 where nscd is installed and used. Common scenarios:
  • Servers using nscd to accelerate user/group/host lookups (some enterprise deployments).
  • Containers or container hosts where nscd is in use inside containers or on the host.
  • Multi‑tenant services that depend on name resolution reliability.
• Systems not running nscd or NSS clients that avoid nscd caching are less likely to be affected in practice.
• Distributions that backported or cherry‑picked the optimization into custom glibc packages must treat this as potentially relevant even if nominal glibc version numbers differ. (nvd.nist.gov)

Practical inventory steps:

• Run getconf GNU_LIBC_VERSION or ldd --version to identify the installed glibc version on x86_64 hosts. (clrn.org)
• Check whether nscd is installed and active: systemctl status nscd or ps aux | grep nscd. If it’s not present or disabled, immediate risk is lower. (docs.redhat.com)

---

Risk assessment and exploitability​

Public scoring and telemetry say the issue is medium severity with an emphasis on availability impact; EPSS is low indicating limited likelihood of immediate widespread exploitation. That said, availability attacks are meaningful in production: if name resolution frequently fails or nscd crashes in busy environments, the resulting outages can cascade into authentication failures, service failures, or cluster instability. (tenable.com)
Attack model notes:

• Vector: local. An attacker needs the ability to trigger or generate high nscd load or a thread interleaving scenario on the target host. This generally implies local access or an application that can cause the precise concurrency pattern, not remote unauthenticated exploitation. (nvd.nist.gov)
• Likelihood: low in default installations, higher in specially crafted or high‑concurrency environments (multi‑user servers, build/test farms, large service nodes). (openwall.com)
• Impact: outages and process restarts; in critical clustered systems this can produce service downtime and user‑facing errors. (nvd.nist.gov)

---

Detection and hunting — what to look for​

If you manage Linux servers, prioritize detection where nscd is present and glibc matches affected builds.
Suggested immediate checks:

• Confirm glibc version: getconf GNU_LIBC_VERSION or ldd --version. (clrn.org)
• Confirm whether nscd is enabled: systemctl is-enabled nscd && systemctl status nscd or ps -ef | grep [n]scd. (docs.redhat.com)
• Search logs for crashes and segfaults:
  • journalctl -u nscd --since "24 hours ago" | grep -iE "segfault|signal|core|fault"
  • journalctl -k | grep -i nscd or dmesg | grep -i nscd
  • Generic crash hunting: grep -iE "segfault|core dumped|Aborted" /var/log/*
• Monitor for service‑level failures that could be downstream effects of name resolution failures: authentication errors (SSSD/LDAP), queued job failures, DNS resolution timeouts.

Logging/SIEM patterns to track:

• Repeated nscd restarts or crashes within a short window.
• In clustered environments, transient authentication or host‑lookup failures coincident with nscd instability.
• Alerts for processes crashing with glibc stack frames where memcmp or nscd client functions are present.

Because glibc is a core library, an incident response playbook should include steps to gather core dumps (where permitted), preserve affected packages and system state, and coordinate a controlled remediation to avoid further instability. (nvd.nist.gov)

---

Immediate mitigations and recommended remediation steps​

1. Inventory and prioritize: identify hosts with (a) x86_64 glibc builds that include the memcmp optimization and (b) nscd installed/active. Use getconf GNU_LIBC_VERSION and systemctl status nscd. (clrn.org)
2. Apply vendor patches: upgrade glibc packages from your distribution’s security repositories as soon as patches are available. Upstream has backported fixes; distributions will publish patched libc packages — treat these updates as high priority for affected hosts. Confirm the distribution advisory and package versions before rolling out at scale. (openwall.com)
3. Restart affected processes (or reboot) to ensure the patched libc is used:
   • After a libc/glibc package upgrade, running processes will continue to use the old library image until restarted, so update alone does not guarantee protection. Use tools such as needrestart to safely identify and restart affected daemons, or plan a controlled reboot for hosts where restarting every process is impractical. Many distribution packaging scripts and documentation explicitly recommend restarting services or rebooting after a libc update. (debian.org)
4. If an immediate patch is not available and nscd is not required for your workload, consider temporarily disabling nscd to prevent the crash vector:
   • systemctl stop nscd
   • systemctl disable nscd
     Remember: disabling nscd may increase lookup latency and change behavior for name resolution caching. Test and monitor accordingly. Red Hat and other vendor guidance often suggests disabling nscd on identity management clients and leveraging SSSD if appropriate. (docs.redhat.com)
5. For high‑availability/clustered services: perform a staggered upgrade and reboot plan to avoid simultaneous restarts; drain nodes from service pools, patch, restart, then return to service — use your orchestration tools to maintain continuity.
6. Preserve evidence: if you observe crashes, collect journalctl logs, core dumps (where permissible), and the current package list (rpm -qa/dpkg -l) so incident response and distribution vendors can analyze the failure modes.
7. Communicate with vendors: if you run a distribution that builds glibc with non‑standard patches (common in enterprise Linux derivatives), confirm with your vendor whether their glibc builds included the memcmp optimization and whether the vendor has released a patched libc package. (nvd.nist.gov)

---

Step‑by‑step playbook (practical)​

1. Identify candidate hosts:
   • getconf GNU_LIBC_VERSION or ldd --version
   • systemctl status nscd || ps -ef | grep [n]scd
2. If glibc is vulnerable and you have a patched package available:
   • Apply the patch using your distribution’s package manager (example patterns):
     • Debian/Ubuntu: apt update && apt install --only-upgrade libc6
     • RHEL/CentOS/Fedora: dnf update glibc or yum update glibc
     • (Use your distro’s exact package name and test in staging first.)
   • Run needrestart or restart affected services; if in doubt, schedule a reboot. (debian.org)
3. If a patch is not yet published:
   • Consider stopping and disabling nscd (test impact first):
     • systemctl stop nscd && systemctl disable nscd
   • Monitor logs for any increase in resolution latency or authentication issues.
4. In cluster environments:
   • Patch one node at a time; drain workloads before patching; validate before reintroducing to the pool.
5. Post‑remediation:
   • Validate that ldd --version or package manager shows the patched glibc version.
   • Check logs for absence of new nscd crashes.
   • Re-enable nscd only if required and after the glibc update is confirmed.

Caveat: the precise package names, service names, and restart semantics vary by distribution and environment — treat the steps above as a template and confirm with your distro vendor guidance. (debian.org)

---

Strengths in the public response — and gaps to watch​

What the community and maintainers did well:

• The upstream glibc team published a focused advisory (GLIBC‑SA‑2026‑0004) quickly after fix availability, and maintainers backported the fix to affected branches. That rapid upstream remediation reduces the window of exposure for distributions to consume and ship fixes. (openwall.com)
• Central catalogers (NVD, Tenable) registered the CVE promptly, giving defenders a canonical identifier to track and correlate across tooling and ticketing. (nvd.nist.gov)

Where defenders should remain cautious:

• Distribution lag: even with an upstream fix, many environments are only as secure as their distribution’s release cadence and the organization’s patch management pipeline. Distributors that compile or patch glibc independently may not immediately publish packages; organizations must validate vendor advisories before assuming remediation. (nvd.nist.gov)
• Partial mitigations: disabling nscd reduces immediate risk but may introduce operational impact (increased NSS lookup latency, unexpected behavior in authentication). Always test and communicate changes. (docs.redhat.com)
• Runtime update complexity: glibc is fundamental; upgrading it in production requires careful orchestration. Simply upgrading packages without restarting processes will not remove the vulnerability from already‑running processes — so operational playbooks must include controlled restarts or reboots. Debian/Ubuntu documentation and packaging scripts explicitly call this out. (debian.org)

---

Recommendations for different audiences​

For Linux system administrators​

• Prioritize inventory: list x86_64 hosts that run nscd and check glibc version. (clrn.org)
• Patch promptly from the distribution’s security channels; coordinate reboots or rolling restarts so that the patched libc is actually used in running processes. Use needrestart or your orchestration system to handle restarts safely. (debian.org)
• If a patch is not yet available, temporarily disable nscd on non‑critical systems and monitor behavior. Test the effect on authentication and name resolution before applying the change widely. (docs.redhat.com)

For security teams (blue teams / SOC)​

• Add detection rules for nscd crashes and correlated service errors. Instrument logs and create alerts for repeated nscd restarts, segfaults, or core dumps. Maintain a runbook for isolating and patching affected nodes.
• Communicate with application teams that depend on NSS lookups (LDAP, Kerberos, cluster services) so they know to expect possible transient failures during rolling patch windows.

For distribution and platform operators​

• If you maintain custom or downstream glibc builds, perform a binary audit to confirm whether the memcpy/memcmp optimization was included and, if so, backport the upstream fix or rebuild without the optimization until the fix is available. Public advisories explicitly call out distributions that cherry‑picked the optimization. (nvd.nist.gov)

---

Closing analysis — what this CVE means in practice​

CVE‑2026‑3904 is an important but narrowly scoped vulnerability: it is not a remote code execution or privilege escalation bug, and the documented impact is availability — crashes of the nscd client and dependent applications. The remediation path is straightforward in principle (apply patched glibc packages), but in practice the operational complexity of updating libc across production fleets — and ensuring processes pick up the new library — elevates the work required.
The principal risk vector is not exploit code in the wild but the operational fallout: unpatched fleets, cascading service failures when nscd fails on critical hosts, and confusion where service behavior changes after disabling nscd as a temporary mitigation. For enterprises, the sensible posture is quick inventory, expedited patch testing and staging, coordinated rolling restarts (or controlled reboots), and clear cross‑team communication with application and identity teams.
Finally, note that the upstream advisory and the NVD/Tenable entries are the authoritative technical records for this issue; the Microsoft Security Update Guide also lists the CVE record identifier in its catalog, but its UI may require a JavaScript‑enabled browser to render the vendor page contents. Where possible, rely on upstream glibc advisories and your distribution’s security bulletins for the precise package versions to consume. (openwall.com)

---

Appendix — quick commands and checks (copy/paste friendly)

• Check glibc version:
  • getconf GNU_LIBC_VERSION — prints installed glibc version. (clrn.org)
  • ldd --version — shows glibc version used by ldd. (clrn.org)
• Check and stop nscd:
  • systemctl status nscd
  • systemctl stop nscd && systemctl disable nscd (test before wide use). (docs.redhat.com)
• Patch examples (replace with distro‑specific validated commands):
  1. Debian/Ubuntu: apt update && apt install --only-upgrade libc6 then needrestart or schedule reboot. (debian.org)
  2. RHEL/CentOS/Fedora: dnf update glibc (or yum update glibc) then restart services / reboot as required. (ubuntu.com)
• Log checks:
  • journalctl -u nscd --since "1 hour ago" | grep -iE "segfault|core|Aborted|signal"
  • dmesg | grep -i nscd
• Post‑update validation:
  • Re‑run getconf GNU_LIBC_VERSION and ensure the package manager shows the new libc package version (dpkg -l | grep libc6 or rpm -q glibc).

Conservative, well‑orchestrated patching and test plans will neutralize the risk from CVE‑2026‑3904 while avoiding the operational interruptions that can themselves become security incidents. (nvd.nist.gov)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center