linux-kernel - Re: [BISECT BUG] NFS v4 root not working after 6d972518b821 ("NFS: Add fs

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: <b31b09abeea4982e038b0e66e45889bb2c9df750.camel@hammerspace.com>
Date:   Fri, 17 Jan 2020 15:17:28 +0000
From:   Trond Myklebust <trondmy@...merspace.com>
To:     "dhowells@...hat.com" <dhowells@...hat.com>,
        "krzk@...nel.org" <krzk@...nel.org>
CC:     "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "smayhew@...hat.com" <smayhew@...hat.com>,
        "anna.schumaker@...app.com" <anna.schumaker@...app.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>
Subject: Re: [BISECT BUG] NFS v4 root not working after 6d972518b821 ("NFS:
 Add fs_context support.")

On Fri, 2020-01-17 at 15:12 +0000, David Howells wrote:
> Krzysztof Kozlowski <krzk@...nel.org> wrote:
> 
> > mount.nfs4 -o vers=4,nolock 192.168.1.10:/srv/nfs/odroidhc1
> > /new_root
> 
> Okay, it looks like the mount command makes two attempts at mounting.
> Firstly, it does this:
> 
> > [   22.938314] NFSOP 'source=192.168.1.10:/srv/nfs/odroidhc1'
> > [   22.942638] NFSOP 'nolock=(null)'
> > [   22.945772] NFSOP 'vers=4.2'
> > [   22.948660] NFSOP 'addr=192.168.1.10'
> > [   22.952350] NFSOP 'clientaddr=192.168.1.12'
> > [   22.956831] NFS4: Couldn't follow remote path
> 
> Which accepts the "vers=4.2" parameter as there's no check that that
> is
> actually valid given the configuration, but then fails
> later.  Secondly, it
> does this:
> 
> > [   22.971001] NFSOP 'source=192.168.1.10:/srv/nfs/odroidhc1'
> > [   22.975217] NFSOP 'nolock=(null)'
> > [   22.978444] NFSOP 'vers=4'
> > [   22.981265] NFSOP 'minorversion=1'
> > [   22.984513] NFS: Value for 'minorversion' out of range
> > mount.nfs4: Numerical result out of range
> 
> which fails because of the minorversion=1 specification, where the
> kernel
> config didn't enable NFS_V4_1.
> 
> It looks like it ought to have failed prior to these patches in the
> same way:
> 
> 		case Opt_minorversion:
> 			if (nfs_get_option_ul(args, &option))
> 				goto out_invalid_value;
> 			if (option > NFS4_MAX_MINOR_VERSION)
> 				goto out_invalid_value;
> 			mnt->minorversion = option;
> 			break;
> 

It looks like someone changed the return value from the old EINVAL to
something else? The "Numerical result out of range" message above
suggests it has been changed to EOVERFLOW, which probably is not
supported by 'mount'.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@...merspace.com