<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/net/sunrpc/auth_gss, branch dev</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2015-06-22T18:15:06+00:00</updated>
<entry>
<title>sunrpc: use sg_init_one() in krb5_rc4_setup_enc/seq_key()</title>
<updated>2015-06-22T18:15:06+00:00</updated>
<author>
<name>Fabian Frederick</name>
<email>fabf@skynet.be</email>
</author>
<published>2015-06-16T19:57:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=901f1379f6c9dc2d73b51971d129a6f7d5b9b20a'/>
<id>urn:sha1:901f1379f6c9dc2d73b51971d129a6f7d5b9b20a</id>
<content type='text'>
Don't opencode sg_init_one()

Signed-off-by: Fabian Frederick &lt;fabf@skynet.be&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures</title>
<updated>2015-05-04T16:02:40+00:00</updated>
<author>
<name>Scott Mayhew</name>
<email>smayhew@redhat.com</email>
</author>
<published>2015-04-28T20:29:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9507271d960a1911a51683888837d75c171cd91f'/>
<id>urn:sha1:9507271d960a1911a51683888837d75c171cd91f</id>
<content type='text'>
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 &lt;smayhew@redhat.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Simo Sorce &lt;simo@redhat.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>sunrpc: integer underflow in rsc_parse()</title>
<updated>2015-02-26T20:40:16+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2015-02-24T15:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=76cb4be993c03bf9ec65a58b13f12c679bb041e4'/>
<id>urn:sha1:76cb4be993c03bf9ec65a58b13f12c679bb041e4</id>
<content type='text'>
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 &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Simo Sorce &lt;simo@redhat.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>svcrpc: fix memory leak in gssp_accept_sec_context_upcall</title>
<updated>2015-02-17T23:09:02+00:00</updated>
<author>
<name>David Ramos</name>
<email>daramos@stanford.edu</email>
</author>
<published>2015-02-13T21:11:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a1d1e9be5a1dafe0ddc2181a9201c2ae29c71eff'/>
<id>urn:sha1:a1d1e9be5a1dafe0ddc2181a9201c2ae29c71eff</id>
<content type='text'>
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-&gt;pages.  The second then frees the pages
pointed to by the arg-&gt;pages array, but not the array itself.

Reported-by: David A. Ramos &lt;daramos@stanford.edu&gt;
Fixes: 9dfd87da1aeb ("rpc: fix huge kmalloc's in gss-proxy”)
Signed-off-by: David A. Ramos &lt;daramos@stanford.edu&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>sunrpc: move rq_splice_ok flag into rq_flags</title>
<updated>2014-12-09T16:22:21+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@primarydata.com</email>
</author>
<published>2014-11-19T12:51:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=779fb0f3af3089daa2e88cf8ef0ef0c5d2fecb40'/>
<id>urn:sha1:779fb0f3af3089daa2e88cf8ef0ef0c5d2fecb40</id>
<content type='text'>
Signed-off-by: Jeff Layton &lt;jlayton@primarydata.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>sunrpc: eliminate RPC_DEBUG</title>
<updated>2014-11-24T22:31:46+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@primarydata.com</email>
</author>
<published>2014-11-17T21:58:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f895b252d4edf66b2895fb5a7b17a638665f3e1f'/>
<id>urn:sha1:f895b252d4edf66b2895fb5a7b17a638665f3e1f</id>
<content type='text'>
It's always set to whatever CONFIG_SUNRPC_DEBUG is, so just use that.

Signed-off-by: Jeff Layton &lt;jlayton@primarydata.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
</content>
</entry>
<entry>
<title>sunrpc: fix sleeping under rcu_read_lock in gss_stringify_acceptor</title>
<updated>2014-11-13T18:15:49+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@primarydata.com</email>
</author>
<published>2014-11-13T12:30:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b3ecba096729f521312d1863ad22530695527aed'/>
<id>urn:sha1:b3ecba096729f521312d1863ad22530695527aed</id>
<content type='text'>
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: [&lt;ffffffffa01c0a9a&gt;] nfs4_discover_server_trunking+0x4a/0x2f0 [nfsv4]
    #1:  (rcu_read_lock){......}, at: [&lt;ffffffffa00e3185&gt;] gss_stringify_acceptor+0x5/0xb0 [auth_rpcgss]
    Preemption disabled at:[&lt;ffffffff81a4f082&gt;] 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:
    [&lt;ffffffff81a534cf&gt;] dump_stack+0x4f/0x7c
    [&lt;ffffffff81097854&gt;] __might_sleep+0x114/0x180
    [&lt;ffffffff8118e4f3&gt;] __kmalloc+0x1a3/0x280
    [&lt;ffffffffa00e31d8&gt;] gss_stringify_acceptor+0x58/0xb0 [auth_rpcgss]
    [&lt;ffffffffa00e3185&gt;] ? gss_stringify_acceptor+0x5/0xb0 [auth_rpcgss]
    [&lt;ffffffffa006b438&gt;] rpcauth_stringify_acceptor+0x18/0x30 [sunrpc]
    [&lt;ffffffffa01b0469&gt;] nfs4_proc_setclientid+0x199/0x380 [nfsv4]
    [&lt;ffffffffa01b04d0&gt;] ? nfs4_proc_setclientid+0x200/0x380 [nfsv4]
    [&lt;ffffffffa01bdf1a&gt;] nfs40_discover_server_trunking+0xda/0x150 [nfsv4]
    [&lt;ffffffffa01bde45&gt;] ? nfs40_discover_server_trunking+0x5/0x150 [nfsv4]
    [&lt;ffffffffa01c0acf&gt;] nfs4_discover_server_trunking+0x7f/0x2f0 [nfsv4]
    [&lt;ffffffffa01c8e24&gt;] nfs4_init_client+0x104/0x2f0 [nfsv4]
    [&lt;ffffffffa01539b4&gt;] nfs_get_client+0x314/0x3f0 [nfs]
    [&lt;ffffffffa0153780&gt;] ? nfs_get_client+0xe0/0x3f0 [nfs]
    [&lt;ffffffffa01c83aa&gt;] nfs4_set_client+0x8a/0x110 [nfsv4]
    [&lt;ffffffffa0069708&gt;] ? __rpc_init_priority_wait_queue+0xa8/0xf0 [sunrpc]
    [&lt;ffffffffa01c9b2f&gt;] nfs4_create_server+0x12f/0x390 [nfsv4]
    [&lt;ffffffffa01c1472&gt;] nfs4_remote_mount+0x32/0x60 [nfsv4]
    [&lt;ffffffff81196489&gt;] mount_fs+0x39/0x1b0
    [&lt;ffffffff81166145&gt;] ? __alloc_percpu+0x15/0x20
    [&lt;ffffffff811b276b&gt;] vfs_kern_mount+0x6b/0x150
    [&lt;ffffffffa01c1396&gt;] nfs_do_root_mount+0x86/0xc0 [nfsv4]
    [&lt;ffffffffa01c1784&gt;] nfs4_try_mount+0x44/0xc0 [nfsv4]
    [&lt;ffffffffa01549b7&gt;] ? get_nfs_version+0x27/0x90 [nfs]
    [&lt;ffffffffa0161a2d&gt;] nfs_fs_mount+0x47d/0xd60 [nfs]
    [&lt;ffffffff81a59c5e&gt;] ? mutex_unlock+0xe/0x10
    [&lt;ffffffffa01606a0&gt;] ? nfs_remount+0x430/0x430 [nfs]
    [&lt;ffffffffa01609c0&gt;] ? nfs_clone_super+0x140/0x140 [nfs]
    [&lt;ffffffff81196489&gt;] mount_fs+0x39/0x1b0
    [&lt;ffffffff81166145&gt;] ? __alloc_percpu+0x15/0x20
    [&lt;ffffffff811b276b&gt;] vfs_kern_mount+0x6b/0x150
    [&lt;ffffffff811b5830&gt;] do_mount+0x210/0xbe0
    [&lt;ffffffff811b54ca&gt;] ? copy_mount_options+0x3a/0x160
    [&lt;ffffffff811b651f&gt;] SyS_mount+0x6f/0xb0
    [&lt;ffffffff81a5c852&gt;] 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: &lt;stable@vger.kernel.org&gt; # v3.17+
Reported-by: "J. Bruce Fields" &lt;bfields@fieldses.org&gt;
Signed-off-by: Jeff Layton &lt;jlayton@primarydata.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'nfs-for-3.17-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs</title>
<updated>2014-08-14T00:13:19+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-08-14T00:13:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=06b8ab55289345ab191bf4bf0e4acc6d4bdf293d'/>
<id>urn:sha1:06b8ab55289345ab191bf4bf0e4acc6d4bdf293d</id>
<content type='text'>
Pull NFS client updates from Trond Myklebust:
 "Highlights include:

   - stable fix for a bug in nfs3_list_one_acl()
   - speed up NFS path walks by supporting LOOKUP_RCU
   - more read/write code cleanups
   - pNFS fixes for layout return on close
   - fixes for the RCU handling in the rpcsec_gss code
   - more NFS/RDMA fixes"

* tag 'nfs-for-3.17-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: (79 commits)
  nfs: reject changes to resvport and sharecache during remount
  NFS: Avoid infinite loop when RELEASE_LOCKOWNER getting expired error
  SUNRPC: remove all refcounting of groupinfo from rpcauth_lookupcred
  NFS: fix two problems in lookup_revalidate in RCU-walk
  NFS: allow lockless access to access_cache
  NFS: teach nfs_lookup_verify_inode to handle LOOKUP_RCU
  NFS: teach nfs_neg_need_reval to understand LOOKUP_RCU
  NFS: support RCU_WALK in nfs_permission()
  sunrpc/auth: allow lockless (rcu) lookup of credential cache.
  NFS: prepare for RCU-walk support but pushing tests later in code.
  NFS: nfs4_lookup_revalidate: only evaluate parent if it will be used.
  NFS: add checks for returned value of try_module_get()
  nfs: clear_request_commit while holding i_lock
  pnfs: add pnfs_put_lseg_async
  pnfs: find swapped pages on pnfs commit lists too
  nfs: fix comment and add warn_on for PG_INODE_REF
  nfs: check wait_on_bit_lock err in page_group_lock
  sunrpc: remove "ec" argument from encrypt_v2 operation
  sunrpc: clean up sparse endianness warnings in gss_krb5_wrap.c
  sunrpc: clean up sparse endianness warnings in gss_krb5_seal.c
  ...
</content>
</entry>
<entry>
<title>sunrpc: remove "ec" argument from encrypt_v2 operation</title>
<updated>2014-08-03T21:05:24+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@primarydata.com</email>
</author>
<published>2014-07-16T10:52:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ec25422c669d38f4e8a83da7f77950094349de48'/>
<id>urn:sha1:ec25422c669d38f4e8a83da7f77950094349de48</id>
<content type='text'>
It's always 0.

Signed-off-by: Jeff Layton &lt;jlayton@primarydata.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
</content>
</entry>
<entry>
<title>sunrpc: clean up sparse endianness warnings in gss_krb5_wrap.c</title>
<updated>2014-08-03T21:05:24+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@primarydata.com</email>
</author>
<published>2014-07-16T10:52:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b36e9c44af00285ea33e78ce8ac91da3d8ac74da'/>
<id>urn:sha1:b36e9c44af00285ea33e78ce8ac91da3d8ac74da</id>
<content type='text'>
Fix the endianness handling in gss_wrap_kerberos_v1 and drop the memset
call there in favor of setting the filler bytes directly.

In gss_wrap_kerberos_v2, get rid of the "ec" variable which is always
zero, and drop the endianness conversion of 0. Sparse handles 0 as a
special case, so it's not necessary.

Signed-off-by: Jeff Layton &lt;jlayton@primarydata.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
</content>
</entry>
</feed>
