BMC/Intel-BMC/linux.git/net/sunrpc/auth_gss, branch dev-4.4

SUNRPC: allow for upcalls for same uid but different gss service

2016-09-07T06:32:36+00:00

commit 9130b8dbc6ac20f2dc5846e1647f5b60eafab6e3 upstream. It's possible to have simultaneous upcalls for the same UIDs but different GSS service. In that case, we need to allow for the upcall to gssd to proceed so that not the same context is used by two different GSS services. Some servers lock the use of context to the GSS service. Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

sunrpc: fix stripping of padded MIC tokens

2016-06-08T01:14:36+00:00

commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 upstream. The length of the GSS MIC token need not be a multiple of four bytes. It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data() would previously only trim mic.len + 4 B. The remaining up to three bytes would then trigger a check in nfs4svc_decode_compoundargs(), leading to a "garbage args" error and mount failure: nfs4svc_decode_compoundargs: compound not properly padded! nfsd: failed to decode arguments! This would prevent older clients using the pre-RFC 4121 MIC format (37-byte MIC including a 9-byte OID) from mounting exports from v3.9+ servers using krb5i. The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off trailing checksum before returning decrypted or integrity authenticated buffer"). Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..." Signed-off-by: Tomáš Trnka Acked-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

sunrpc: avoid warning in gss_key_timeout

2015-10-23T19:57:28+00:00

The gss_key_timeout() function causes a harmless warning in some configurations, e.g. ARM imx_v6_v7_defconfig with gcc-5.2, if the compiler cannot figure out the state of the 'expire' variable across an rcu_read_unlock(): net/sunrpc/auth_gss/auth_gss.c: In function 'gss_key_timeout': net/sunrpc/auth_gss/auth_gss.c:1422:211: warning: 'expire' may be used uninitialized in this function [-Wmaybe-uninitialized] To avoid this warning without adding a bogus initialization, this rewrites the function so the comparison is done inside of the critical section. As a side-effect, it also becomes slightly easier to understand because the implementation now more closely resembles the comment above it. Signed-off-by: Arnd Bergmann Fixes: c5e6aecd034e7 ("sunrpc: fix RCU handling of gc_ctx field") Signed-off-by: J. Bruce Fields

sunrpc: use sg_init_one() in krb5_rc4_setup_enc/seq_key()

2015-06-22T18:15:06+00:00

Don't opencode sg_init_one() Signed-off-by: Fabian Frederick Signed-off-by: J. Bruce Fields

svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures

2015-05-04T16:02:40+00:00

In an environment where the KDC is running Active Directory, the exported composite name field returned in the context could be large enough to span a page boundary. Attaching a scratch buffer to the decoding xdr_stream helps deal with those cases. The case where we saw this was actually due to behavior that's been fixed in newer gss-proxy versions, but we're fixing it here too. Signed-off-by: Scott Mayhew Cc: stable@vger.kernel.org Reviewed-by: Simo Sorce Signed-off-by: J. Bruce Fields

sunrpc: integer underflow in rsc_parse()

2015-02-26T20:40:16+00:00

If we call groups_alloc() with invalid values then it's might lead to memory corruption. For example, with a negative value then we might not allocate enough for sizeof(struct group_info). (We're doing this in the caller for consistency with other callers of groups_alloc(). The other alternative might be to move the check out of all the callers into groups_alloc().) Signed-off-by: Dan Carpenter Reviewed-by: Simo Sorce Signed-off-by: J. Bruce Fields

svcrpc: fix memory leak in gssp_accept_sec_context_upcall

2015-02-17T23:09:02+00:00

Our UC-KLEE tool found a kernel memory leak of 512 bytes (on x86_64) for each call to gssp_accept_sec_context_upcall() (net/sunrpc/auth_gss/gss_rpc_upcall.c). Since it appears that this call can be triggered by remote connections (at least, from a cursory a glance at the call chain), it may be exploitable to cause kernel memory exhaustion. We found the bug in kernel 3.16.3, but it appears to date back to commit 9dfd87da1aeb0fd364167ad199f40fe96a6a87be (2013-08-20). The gssp_accept_sec_context_upcall() function performs a pair of calls to gssp_alloc_receive_pages() and gssp_free_receive_pages(). The first allocates memory for arg->pages. The second then frees the pages pointed to by the arg->pages array, but not the array itself. Reported-by: David A. Ramos Fixes: 9dfd87da1aeb ("rpc: fix huge kmalloc's in gss-proxy”) Signed-off-by: David A. Ramos Signed-off-by: J. Bruce Fields

sunrpc: move rq_splice_ok flag into rq_flags

2014-12-09T16:22:21+00:00

Signed-off-by: Jeff Layton Signed-off-by: J. Bruce Fields

sunrpc: eliminate RPC_DEBUG

2014-11-24T22:31:46+00:00

It's always set to whatever CONFIG_SUNRPC_DEBUG is, so just use that. Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust

sunrpc: fix sleeping under rcu_read_lock in gss_stringify_acceptor

2014-11-13T18:15:49+00:00

Bruce reported that he was seeing the following BUG pop: BUG: sleeping function called from invalid context at mm/slab.c:2846 in_atomic(): 0, irqs_disabled(): 0, pid: 4539, name: mount.nfs 2 locks held by mount.nfs/4539: #0: (nfs_clid_init_mutex){+.+.+.}, at: [] nfs4_discover_server_trunking+0x4a/0x2f0 [nfsv4] #1: (rcu_read_lock){......}, at: [] gss_stringify_acceptor+0x5/0xb0 [auth_rpcgss] Preemption disabled at:[] printk+0x4d/0x4f CPU: 3 PID: 4539 Comm: mount.nfs Not tainted 3.18.0-rc1-00013-g5b095e9 #3393 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 ffff880021499390 ffff8800381476a8 ffffffff81a534cf 0000000000000001 0000000000000000 ffff8800381476c8 ffffffff81097854 00000000000000d0 0000000000000018 ffff880038147718 ffffffff8118e4f3 0000000020479f00 Call Trace: [] dump_stack+0x4f/0x7c [] __might_sleep+0x114/0x180 [] __kmalloc+0x1a3/0x280 [] gss_stringify_acceptor+0x58/0xb0 [auth_rpcgss] [] ? gss_stringify_acceptor+0x5/0xb0 [auth_rpcgss] [] rpcauth_stringify_acceptor+0x18/0x30 [sunrpc] [] nfs4_proc_setclientid+0x199/0x380 [nfsv4] [] ? nfs4_proc_setclientid+0x200/0x380 [nfsv4] [] nfs40_discover_server_trunking+0xda/0x150 [nfsv4] [] ? nfs40_discover_server_trunking+0x5/0x150 [nfsv4] [] nfs4_discover_server_trunking+0x7f/0x2f0 [nfsv4] [] nfs4_init_client+0x104/0x2f0 [nfsv4] [] nfs_get_client+0x314/0x3f0 [nfs] [] ? nfs_get_client+0xe0/0x3f0 [nfs] [] nfs4_set_client+0x8a/0x110 [nfsv4] [] ? __rpc_init_priority_wait_queue+0xa8/0xf0 [sunrpc] [] nfs4_create_server+0x12f/0x390 [nfsv4] [] nfs4_remote_mount+0x32/0x60 [nfsv4] [] mount_fs+0x39/0x1b0 [] ? __alloc_percpu+0x15/0x20 [] vfs_kern_mount+0x6b/0x150 [] nfs_do_root_mount+0x86/0xc0 [nfsv4] [] nfs4_try_mount+0x44/0xc0 [nfsv4] [] ? get_nfs_version+0x27/0x90 [nfs] [] nfs_fs_mount+0x47d/0xd60 [nfs] [] ? mutex_unlock+0xe/0x10 [] ? nfs_remount+0x430/0x430 [nfs] [] ? nfs_clone_super+0x140/0x140 [nfs] [] mount_fs+0x39/0x1b0 [] ? __alloc_percpu+0x15/0x20 [] vfs_kern_mount+0x6b/0x150 [] do_mount+0x210/0xbe0 [] ? copy_mount_options+0x3a/0x160 [] SyS_mount+0x6f/0xb0 [] system_call_fastpath+0x12/0x17 Sleeping under the rcu_read_lock is bad. This patch fixes it by dropping the rcu_read_lock before doing the allocation and then reacquiring it and redoing the dereference before doing the copy. If we find that the string has somehow grown in the meantime, we'll reallocate and try again. Cc: # v3.17+ Reported-by: "J. Bruce Fields" Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust