After a failed cache insertion, addgetnetgrentX tries to send the non-existing response after the not-found header. In addinnetgrX, addgetnetgrentX may have produced a NULL result, indicating a not-found status, but this is not handled in the subsequent code that prepares the record that will be sent out to the client.
Fixed for glibc 2.40 via: commit b048a482f088e53144d26a61c390bed0210f49f2 Author: Florian Weimer <fweimer@redhat.com> Date: Thu Apr 25 15:01:07 2024 +0200 CVE-2024-33600: nscd: Avoid null pointer crashes after notfound response (bug 31678) The addgetnetgrentX call in addinnetgrX may have failed to produce a result, so the result variable in addinnetgrX can be NULL. Use db->negtimeout as the fallback value if there is no result data; the timeout is also overwritten below. Also avoid sending a second not-found response. (The client disconnects after receiving the first response, so the data stream did not go out of sync even without this fix.) It is still beneficial to add the negative response to the mapping, so that the client can get it from there in the future, instead of going through the socket. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> commit 7835b00dbce53c3c87bbbb1754a95fb5e58187aa Author: Florian Weimer <fweimer@redhat.com> Date: Thu Apr 25 15:01:07 2024 +0200 CVE-2024-33600: nscd: Do not send missing not-found response in addgetnetgrentX (bug 31678) If we failed to add a not-found response to the cache, the dataset point can be null, resulting in a null pointer dereference. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>