kernel.git/fs/nfs, branch linux-3.18.y

NFS: Forbid setting AF_INET6 to "struct sockaddr_in"->sin_family.

2019-05-16T07:17:14Z

commit 7c2bd9a39845bfb6d72ddb55ce737650271f6f96 upstream. syzbot is reporting uninitialized value at rpc_sockaddr2uaddr() [1]. This is because syzbot is setting AF_INET6 to "struct sockaddr_in"->sin_family (which is embedded into user-visible "struct nfs_mount_data" structure) despite nfs23_validate_mount_data() cannot pass sizeof(struct sockaddr_in6) bytes of AF_INET6 address to rpc_sockaddr2uaddr(). Since "struct nfs_mount_data" structure is user-visible, we can't change "struct nfs_mount_data" to use "struct sockaddr_storage". Therefore, assuming that everybody is using AF_INET family when passing address via "struct nfs_mount_data"->addr, reject if its sin_family is not AF_INET. [1] https://syzkaller.appspot.com/bug?id=599993614e7cbbf66bc2656a919ab2a95fb5d75c Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

nfs: Fix NULL pointer dereference of dev_name

2019-03-23T07:18:56Z

[ Upstream commit 80ff00172407e0aad4b10b94ef0816fc3e7813cb ] There is a NULL pointer dereference of dev_name in nfs_parse_devname() The oops looks something like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 ... RIP: 0010:nfs_fs_mount+0x3b6/0xc20 [nfs] ... Call Trace: ? ida_alloc_range+0x34b/0x3d0 ? nfs_clone_super+0x80/0x80 [nfs] ? nfs_free_parsed_mount_data+0x60/0x60 [nfs] mount_fs+0x52/0x170 ? __init_waitqueue_head+0x3b/0x50 vfs_kern_mount+0x6b/0x170 do_mount+0x216/0xdc0 ksys_mount+0x83/0xd0 __x64_sys_mount+0x25/0x30 do_syscall_64+0x65/0x220 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fix this by adding a NULL check on dev_name Signed-off-by: Yao Liu Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin

NFS: nfs_compare_mount_options always compare auth flavors.

2019-02-20T09:09:01Z

[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ] This patch removes the check from nfs_compare_mount_options to see if a `sec' option was passed for the current mount before comparing auth flavors and instead just always compares auth flavors. Consider the following scenario: You have a server with the address 192.168.1.1 and two exports /export/a and /export/b. The first export supports `sys' and `krb5' security, the second just `sys'. Assume you start with no mounts from the server. The following results in EIOs being returned as the kernel nfs client incorrectly thinks it can share the underlying `struct nfs_server's: $ mkdir /tmp/{a,b} $ sudo mount -t nfs -o vers=3,sec=krb5 192.168.1.1:/export/a /tmp/a $ sudo mount -t nfs -o vers=3 192.168.1.1:/export/b /tmp/b $ df >/dev/null df: ‘/tmp/b’: Input/output error Signed-off-by: Chris Perl Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin

NFSv4.1: Fix the r/wsize checking

2018-11-22T06:32:44Z

commit 943cff67b842839f4f35364ba2db5c2d3f025d94 upstream. The intention of nfs4_session_set_rwsize() was to cap the r/wsize to the buffer sizes negotiated by the CREATE_SESSION. The initial code had a bug whereby we would not check the values negotiated by nfs_probe_fsinfo() (the assumption being that CREATE_SESSION will always negotiate buffer values that are sane w.r.t. the server's preferred r/wsizes) but would only check values set by the user in the 'mount' command. The code was changed in 4.11 to _always_ set the r/wsize, meaning that we now never use the server preferred r/wsizes. This is the regression that this patch fixes. Also rename the function to nfs4_session_limit_rwsize() in order to avoid future confusion. Fixes: 033853325fe3 (NFSv4.1 respect server's max size in CREATE_SESSION") Cc: stable@vger.kernel.org # v4.11+ Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

nfs: fix high load average due to callback thread sleeping

2018-11-10T15:39:17Z

[ Upstream commit 5d05e54af3cdbb13cf19c557ff2184781b91a22c ] Chuck pointed out a problem that crept in with commit 6ffa30d3f734 (nfs: don't call blocking operations while !TASK_RUNNING). Linux counts tasks in uninterruptible sleep against the load average, so this caused the system's load average to be pinned at at least 1 when there was a NFSv4.1+ mount active. Not a huge problem, but it's probably worth fixing before we get too many complaints about it. This patch converts the code back to use TASK_INTERRUPTIBLE sleep, simply has it flush any signals on each loop iteration. In practice no one should really be signalling this thread at all, so I think this is reasonably safe. With this change, there's also no need to game the hung task watchdog so we can also convert the schedule_timeout call back to a normal schedule. Cc: Reported-by: Chuck Lever Signed-off-by: Jeff Layton Tested-by: Chuck Lever Fixes: commit 6ffa30d3f734 (“nfs: don't call blocking . . .”) Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin

NFSv4: Remove incorrect check in can_open_delegated()

2018-11-10T15:39:15Z

[ Upstream commit 4e379d36c050b0117b5d10048be63a44f5036115 ] Remove an incorrect check for NFS_DELEGATION_NEED_RECLAIM in can_open_delegated(). We are allowed to cache opens even in a situation where we're doing reboot recovery. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin

NFS: Ignore transport protocol when detecting server trunking

2018-11-10T15:39:15Z

[ Upstream commit 7a01edf0058df98d6cc734c5a4ecc51f929a86ec ] Detect server trunking across transport protocols. Otherwise, an RDMA mount and a TCP mount of the same server will end up with separate nfs_clients using the same clientid4. Reported-by: Dai Ngo Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin

NFSv4/v4.1: Verify the client owner id during trunking detection

2018-11-10T15:39:15Z

[ Upstream commit 55b9df93ddd684cbc4c2dee9b8a99f6e48348212 ] While we normally expect the NFSv4 client to always send the same client owner to all servers, there are a couple of situations where that is not the case: 1) In NFSv4.0, switching between use of '-omigration' and not will cause the kernel to switch between using the non-uniform and uniform client strings. 2) In NFSv4.1, or NFSv4.0 when using uniform client strings, if the uniquifier string is suddenly changed. This patch will catch those situations by checking the client owner id in the trunking detection code, and will do the right thing if it notices that the strings differ. Cc: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin

NFSv4: Cache the NFSv4/v4.1 client owner_id in the struct nfs_client

2018-11-10T15:39:15Z

[ Upstream commit ceb3a16c070c403f5f9ca46b46cf2bb79ea11750 ] Ensure that we cache the NFSv4/v4.1 client owner_id so that we can verify it when we're doing trunking detection. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin

pnfs/blocklayout: off by one in bl_map_stripe()

2018-09-09T18:07:55Z

commit 0914bb965e38a055e9245637aed117efbe976e91 upstream. "dev->nr_children" is the number of children which were parsed successfully in bl_parse_stripe(). It could be all of them and then, in that case, it is equal to v->stripe.volumes_count. Either way, the > should be >= so that we don't go beyond the end of what we're supposed to. Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by: Dan Carpenter Reviewed-by: Christoph Hellwig Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman