ypserv-1.3.7 uses the ndbm functions improperly in the functions,
ypproc_all_2_svc() and ypdb_nextkey(). Depending on the keys in the NIS map
being accessed through the database functions, this causes the forked
ypserv child process to loop endlessly. On the client side, the ypcat
eventually times out with an error. E.G.:

healey root> ypcat -k auto.home
ypcat -k auto.home
yp_all: clnt_call: RPC: Timed out
No such map auto.home. Reason: Internal NIS error

The problem is that ndbm library considers the memory pointed to by the
dptr field of the datum structure as static and asserts that this memory
may be (and is!) changed by subsequent calls into the ndbm functions.
Here's a quote from the ndbm(3b) man page on an IRIX64 6.5 machine (I
couldn't find any Linux documentation on ndbm, only gdbm):

Dptr pointers returned by these subroutines point into static storage
     that is changed by subsequent calls.

I also verified that ndbm operates this way by looking at the gdbm source
code when it operates in ndbm compatibility mode.

As dbm_firstkey() and dbm_nextkey() get called repeatedly in
ypdb_nextkey(), they overwrite the contents of the key passed in as a
parameter to the ypdb_nextkey() routine with the key value of the key
returned by dbm_nextkey(). Not good.

I'm new at Linux patches, but here's my attempt at providing a patch that
fixes the problem in the proper format:

--- server.c    Sat Mar  4 21:22:55 2000
+++ fixed.server.c      Sat Mar  4 20:58:21 2000
@@ -1079,6 +1079,13 @@
        {
           datum dkey = ypdb_firstkey (data->dbm);

+#if defined(HAVE_NDBM)
+         /* XXX Replace strncmp */
+         while (dkey.dptr != NULL && strncmp (dkey.dptr, "YP_", 3) == 0)
+         {
+             dkey = dbm_nextkey (data->dbm);
+         }
+#else
          /* XXX Replace strncmp */
          while (dkey.dptr != NULL && strncmp (dkey.dptr, "YP_", 3) == 0)
            {
@@ -1086,6 +1093,7 @@
              dkey = ypdb_nextkey (data->dbm, tkey);
              ypdb_free (tkey.dptr);
            }
+#endif

           if (dkey.dptr != NULL)
             {

Since I #ifdefed this code appropriately, I hope it is fairly safe for
compatibility with other database facilities that ypserv might use.
Still, I'd be interested in communicating with the maintainer (Thorsten
Kukuk?).

Here is the auto.home file I used to cause the problem (other of my NIS
maps caused it as well - netgroup, passwd):

khp		-fstype=nfs		edsel:/home/khp

I don't know the hashing scheme used by ndbm, but it may help in
reproducing the bug to have the map be small, e.g. one entry only as above.

I didn't dig into the ndbm code in glibc so I can't say how easily this bug
will reproduce on other systems. It might depend on how the dbm* routines
actually handle the static storage into which point these dptr fields. On
my machine, the problem is eminently reproducible. BTW, other weird bugs
may occur due to the fact that the ypproc_all_2_svc() routine frees the
memory pointed to by tkey.dptr, memory that ndbm thinks it owns. I don't
know what sort of database corruption this might cause if any. A quick grep
of the ypserv code did show a lot of other calls to ypdb_free() but I
didn't check other places in the code to see if there are similar bugs
elsewhere.