It looks to me like it's somehow related to NFSv4, as the 
/var/log/messages files on the affected clients contain repeated lines like:

nfsidmap[7508]: Failed to add child keyring: Operation not permitted

along with call traces from the hung firefox processes

> kernel: Call Trace:
> kernel: [<ffffffffa06c8912>] ? nfs_permission+0xb2/0x1e0 [nfs]
> kernel: [<ffffffff8123bdaf>] ? security_inode_permission+0x1f/0x30
> kernel: [<ffffffff81548ea6>] __mutex_lock_slowpath+0x96/0x210
> kernel: [<ffffffff815489cb>] mutex_lock+0x2b/0x50
> kernel: [<ffffffff811acc96>] do_filp_open+0x2d6/0xd20
> kernel: [<ffffffffa06ceeab>] ? nfs_attribute_cache_expired+0x1b/0x70 [nfs]
> kernel: [<ffffffff8119f884>] ? cp_new_stat+0xe4/0x100
> kernel: [<ffffffff812a749a>] ? strncpy_from_user+0x4a/0x90
> kernel: [<ffffffff811ba252>] ? alloc_fd+0x92/0x160
> kernel: [<ffffffff81196bd7>] do_sys_open+0x67/0x130
> kernel: [<ffffffff81196ce0>] sys_open+0x20/0x30
> kernel: [<ffffffff8100b0d2>] system_call_fastpath+0x16/0x1b

The nfs-utils package hasn't updated in a while so nfsidmap itself 
shouldn't have changed, but I see that it uses an in-kernel keyring to 
store the mappings, so it could certainly be affected by a change in the 
kernel.

G.

On 6/21/2016 9:40 AM, Jesse Bren wrote:
> Looks like its not the firefox update at fault but the new kernel,
> which was also released about the same time, not playing nicely with
> our NFS file servers. Hopefully this can be resolved soon, currently
> am having users boot into the previous kernel version
> (2.6.32-573.26.1.el6.x86_64 as opposed to 2.6.32-642.el6.x86_64).
>
> Sorry for the, somewhat, false alarm about firefox.
>
> Jesse
>