On Tue, Oct 16, 2018 at 12:32:29PM -0700, Aditya Kali wrote:
> There is a deadlock on linux stable kernels (tested 4.9 and 4.14) when
> running an executable from an NFS mount when CONFIG_IMA is enabled
> (default IMA policy used).
>
> Repro steps (tested on debian 9 with 4.9 kernel and with 4.14 kernel):
> $ sudo mkdir -p /mnt/nfs
> $ sudo mount -o ro,exec,nolock <ip>:/vol /mnt/nfs/
> # "test.sh" is an executable on the nfs volume
> $ /mnt/nfs/test.sh
> <deadlock>
>
> The following stack trace shows the deadlock.
>
> [ 2479.260272] bash D 0 25187 25140 0x00000080
> [ 2479.267680] ffff93f4d9eec000 0000000000000000 ffff93f4dc211040
> ffff93f4ffd18980
> [ 2479.278602] ffff93f4dd8370c0 ffffbc2ac386b8f0 ffffffffbde0fed9
> 0000000000000000
> [ 2479.288154] 0000000000000046 ffff93f4ffd18980 ffffffffbd8a2cda
> ffff93f4dc211040
> [ 2479.297712] Call Trace:
> [ 2479.300311] [<ffffffffbde0fed9>] ? __schedule+0x239/0x6f0
> [ 2479.306005] [<ffffffffbd8a2cda>] ? check_preempt_curr+0x7a/0x90
> [ 2479.313524] [<ffffffffbde103c2>] ? schedule+0x32/0x80
> [ 2479.318801] [<ffffffffbde12d30>] ? rwsem_down_read_failed+0xf0/0x150
> [ 2479.326855] [<ffffffffbdb3f054>] ? call_rwsem_down_read_failed+0x14/0x30
> [ 2479.333802] [<ffffffffbde125ec>] ? down_read+0x1c/0x30
> [ 2479.340542] [<ffffffffc050b6b9>] ? nfs_start_io_read+0x19/0x70 [nfs]
> [ 2479.348529] [<ffffffffc0502c6f>] ? nfs_file_read+0x2f/0xa0 [nfs]
> [ 2479.354779] [<ffffffffbda06fed>] ? new_sync_read+0xdd/0x130
> [ 2479.361981] [<ffffffffbdae2a43>] ? integrity_kernel_read+0x43/0x60
> [ 2479.368606] [<ffffffffbdae484c>] ? ima_calc_file_hash+0x36c/0x710
> [ 2479.376312] [<ffffffffbdae453b>] ? ima_calc_file_hash+0x5b/0x710
> [ 2479.382550] [<ffffffffbd98aa86>] ? __alloc_pages_nodemask+0xf6/0x260
> [ 2479.389124] [<ffffffffbdae5485>] ? ima_collect_measurement+0x145/0x1b0
> [ 2479.397258] [<ffffffffbda2e7fb>] ? vfs_getxattr_alloc+0x5b/0x110
> [ 2479.403490] [<ffffffffbdae3c73>] ? process_measurement+0x393/0x550
> [ 2479.409913] [<ffffffffc04a177f>] ? generic_hash_cred+0x2f/0x60 [sunrpc]
> [ 2479.418138] [<ffffffffc04a19c0>] ?
> rpc_lookup_cred_nonblock+0x20/0x20 [sunrpc]
> [ 2479.426972] [<ffffffffc04a058a>] ?
> rpcauth_lookup_credcache+0x9a/0x2c0 [sunrpc]
> [ 2479.434520] [<ffffffffc0465230>] ? nfs3_proc_commit_setup+0x10/0x10 [nfsv3]
> [ 2479.443082] [<ffffffffc050717f>] ?
> nfs_attribute_cache_expired+0x2f/0x80 [nfs]
> [ 2479.450672] [<ffffffffc050749a>] ? nfs_revalidate_inode_rcu+0x1a/0x40 [nfs]
> [ 2479.459215] [<ffffffffc05002de>] ? nfs_do_access+0x29e/0x350 [nfs]
> [ 2479.467010] [<ffffffffbda0e13a>] ? search_binary_handler+0x2a/0x1c0
> [ 2479.473651] [<ffffffffbda0f8fa>] ? do_execveat_common.isra.37+0x5aa/0x790
> [ 2479.482055] [<ffffffffbda0fd05>] ? SyS_execve+0x35/0x40
> [ 2479.487508] [<ffffffffbd803b7d>] ? do_syscall_64+0x8d/0xf0
> [ 2479.494586] [<ffffffffbde14c4e>] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
>
> Both process_measurement() and nfs_start_io_read() try to acquire the
> inode-lock:
>
> process_measurement() {
> ...
> inode_lock(inode); {
> down_write(&inode->i_rwsem);
> }
> ...
> nfs_start_io_read {
> ...
> down_read(&inode->i_rwsem);
> ...
>
> This deadlock is primarily fixed by following commit in linux master
> (since 4.15):
>
> 0d73a55208e94fc9fb6deaeea61438cd3280d4c0 ima: re-introduce own
> integrity cache lock
>
> The complete list of commits required (with clean cherry-picks) to fix
> the issue in 4.14 stable kernel is below:
>
> e2598077dc6a26c9644393e5c21f22a90dbdccdb ima: re-initialize iint->atomic_flags
> 0d73a55208e94fc9fb6deaeea61438cd3280d4c0 ima: re-introduce own
> integrity cache lock
> 50b977481fce90aa5fbda55e330b9d722733e358 EVM: Add support for portable
> signature format
> f3cc6b25dcc5616f0d5c720009b2ac66f97df2ff ima: always measure and audit
> files in policy
>
> For 4.9 kernel, one additional commit is required and there is a minor
> conflict resolution needed:
>
> 19339c251607a3defc7f089511ce8561936fee45 Revert "evm: Translate
> user/group ids relative to s_user_ns when computing HMAC"
>
> Since the kernel deadlock is trivial to trigger for common default
> configurations, I would like to request cherry-picking the above
> commits to linux-stable branches 4.14 and 4.9.
All now queued up, thanks.
greg k-h
