It was found that mount.nfs suffers from the same flaw as other mount helpers (see CVE-2011-1089).  Instead of using addmntent(), nfs-utils implements its own similar function (nfs_addmntent()) which also fails to anticipate whether resource limits would interfere with correctly writing to /etc/mtab.  A local user could use this to trigger corruption of the /etc/mtab file via a process with a small RLIMIT_FSIZE value.

In nfs-utils-1.2.3/support/nfs/nfs_mntent.c:

126 int
127 nfs_addmntent (mntFILE *mfp, struct mntent *mnt) {
128     char *m1, *m2, *m3, *m4;
129     int res;
130 
131     if (fseek (mfp->mntent_fp, 0, SEEK_END))
132         return 1;           /* failure */
133 
134     m1 = mangle(mnt->mnt_fsname);
135     m2 = mangle(mnt->mnt_dir);
136     m3 = mangle(mnt->mnt_type);
137     m4 = mangle(mnt->mnt_opts);
138 
139     res = fprintf (mfp->mntent_fp, "%s %s %s %s %d %d\n",
140                m1, m2, m3, m4, mnt->mnt_freq, mnt->mnt_passno);
141 
142     free(m1);
143     free(m2);
144     free(m3);
145     free(m4);
146     return (res < 0) ? 1 : 0;
147 }

The above function should use fflush() and return failure based on the success of the fflush() call, to ensure it is fully written prior to updating /etc/mtab.  Perhaps something like:

146     return (res < 0) ? 1 : ((fflush(mfp->mntent_fp) == 0) ? 0 : 1);