CVE-2024-33600

What it actually does

Null pointer dereference in nscd binary when cache fails to store a not-found netgroup response, causing client request handling to crash.

Why it matters to the business

Systems using nscd for name service caching may experience unexpected daemon crashes leading to temporary loss of cached lookups and potential service availability issues.

How an attack unfolds

An attacker triggers repeated netgroup lookups that return not-found results; if the cache addition step fails, the subsequent client request path dereferences a null pointer and terminates the nscd process.

How to fix it

Upgrade glibc to the commit 3d1aed874918c466a4477af1da35983ab036690e or later; disable or replace nscd where feasible if the update cannot be applied promptly.

How to confirm the fix worked

Confirm the installed glibc version contains commit 3d1aed874918c466a4477af1da35983ab036690e; exercise netgroup not-found lookup sequences under cache pressure and verify nscd remains stable.

Typical attack path

1. Locate hosts running the nscd daemon
2. Issue netgroup lookup requests designed to produce not-found responses
3. Force or wait for cache-addition failure conditions
4. Trigger follow-on client requests that traverse the faulty code path
5. Observe nscd crash and resulting denial of service

How to detect it

Review system and daemon logs for abrupt nscd terminations, segmentation faults, or null pointer crash signatures around netgroup lookup activity.

• nscd[pid]: segfault at
• nscd: NULL pointer dereference
• /usr/sbin/nscd core dumped

What your security team should do

• Apply the glibc update containing commit 3d1aed874918c466a4477af1da35983ab036690e on all affected systems
• Inventory environments that run the nscd binary and prioritize patching those with external exposure
• Consider disabling nscd if netgroup caching is not required
• Monitor for nscd process restarts after deployment