lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17788.35808.421807.546159@cse.unsw.edu.au>
Date:	Mon, 11 Dec 2006 09:36:16 +1100
From:	Neil Brown <neilb@...e.de>
To:	Olaf Titz <olaf@...red.inka.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.19: OOPS in cat /proc/fs/nfs/exports

On Sunday December 10, olaf@...red.inka.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > What version of nfs-utils are you running?  We haven't been using
> > nfsservctl(3, ...) on 2.6 kernels for ages - which probably explains
> > why exp_export() has suffered so much bit-rot.  When I convinced
> > exportfs to use that nfsservctl I got a very similar oops.
> >
> > This patch fixes it for me.  Does it fix it for you too?
> 
> The patch fixes the problem; however when I tested it, after some
> export/unexport cycles, trying to mount gave me this:
> 
> Dec 10 21:32:10 glotze kernel: kernel BUG at /usr/opt/src/kernel/linux-2.6.19/mm/slab.c:594!
> Dec 10 21:32:10 glotze kernel: invalid opcode: 0000 [#1]

Looks like that might be a bug in the patch I sent you, which I fixed
before I sent it upstream.  Could you try this (against 2.6.19)
instead and confirm that it fixes all problems? thanks.

> 
> Might be unrelated (mountd not exportfs), but perhaps this code has
> got as much bitrot too.
> 
> I've replaced exportfs, mountd and nfsd with a newer version and it
> works now.

What version were you using?  I would really like to know.

> 
> If this nfsservctl functions are not used anymore by the officially
> supported version of system tools, shouldn't that code be removed
> altogether? If OTOH it falls under "don't break userspace interface",
> perhaps there is more left to fix...

Yes, it is a case of "don't break userspace interface" - at least not
without suitable warning and good reason.  So I want the old nfs-utils
to still work. (We might deprecate the old interface one day, but not
yet). 

Thanks,
NeilBrown

-----------------------------------
Fix up some bit-rot in exp_export

The nfsservctl systemcall isn't used but recent nfs-utils releases for
exporting filesystems, and consequently the code that is uses -
exp_export - has suffered some bitrot.

Particular:
  - some newly added fields in 'struct svc_export' are being initialised
    properly.
  - the return value is now always -ENOMEM ...

This patch fixes both these problems.

Signed-off-by: Neil Brown <neilb@...e.de>

### Diffstat output
 ./fs/nfsd/export.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff .prev/fs/nfsd/export.c ./fs/nfsd/export.c
--- .prev/fs/nfsd/export.c	2006-12-11 09:35:46.000000000 +1100
+++ ./fs/nfsd/export.c	2006-12-11 09:35:48.000000000 +1100
@@ -950,6 +950,8 @@ exp_export(struct nfsctl_export *nxp)
 
 	exp = exp_get_by_name(clp, nd.mnt, nd.dentry, NULL);
 
+	memset(&new, 0, sizeof(new));
+
 	/* must make sure there won't be an ex_fsid clash */
 	if ((nxp->ex_flags & NFSEXP_FSID) &&
 	    (fsid_key = exp_get_fsid_key(clp, nxp->ex_dev)) &&
@@ -980,6 +982,9 @@ exp_export(struct nfsctl_export *nxp)
 
 	new.h.expiry_time = NEVER;
 	new.h.flags = 0;
+	new.ex_path = kstrdup(nxp->ex_path, GFP_KERNEL);
+	if (! new.ex_path)
+		goto finish;
 	new.ex_client = clp;
 	new.ex_mnt = nd.mnt;
 	new.ex_dentry = nd.dentry;
@@ -1000,10 +1005,11 @@ exp_export(struct nfsctl_export *nxp)
 		/* failed to create at least one index */
 		exp_do_unexport(exp);
 		cache_flush();
-		err = -ENOMEM;
-	}
-
+	} else
+		err = 0;
 finish:
+	if (new.ex_path)
+		kfree(new.ex_path);
 	if (exp)
 		exp_put(exp);
 	if (fsid_key && !IS_ERR(fsid_key))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ