possible deadlock in proc_pid_attr_write

8 views
Skip to first unread message

syzbot

unread,
Apr 10, 2019, 8:00:20 PM4/10/19
to syzkaller-a...@googlegroups.com
Hello,

syzbot found the following crash on:

HEAD commit: c556d1ff Merge 4.14.78 into android-4.14
git tree: android-4.14
console output: https://syzkaller.appspot.com/x/log.txt?x=112130a9400000
kernel config: https://syzkaller.appspot.com/x/.config?x=71219c5dc171efec
dashboard link: https://syzkaller.appspot.com/bug?extid=40351050f20892504e43
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1655748d400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14c26089400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+403510...@syzkaller.appspotmail.com


======================================================
WARNING: possible circular locking dependency detected
4.14.78+ #22 Not tainted
------------------------------------------------------
syz-executor134/18778 is trying to acquire lock:
(&sig->cred_guard_mutex){+.+.}, at: [<ffffffff93ea126b>]
proc_pid_attr_write+0x16b/0x280 fs/proc/base.c:2590

but task is already holding lock:
(&pipe->mutex/1){+.+.}, at: [<ffffffff93d72e28>] pipe_lock_nested
fs/pipe.c:67 [inline]
(&pipe->mutex/1){+.+.}, at: [<ffffffff93d72e28>] pipe_lock+0x58/0x70
fs/pipe.c:75

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&pipe->mutex/1){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0xf5/0x1480 kernel/locking/mutex.c:893
__pipe_lock fs/pipe.c:88 [inline]
fifo_open+0x156/0x9d0 fs/pipe.c:921
do_dentry_open+0x426/0xda0 fs/open.c:764
vfs_open+0x11c/0x210 fs/open.c:878
do_last fs/namei.c:3408 [inline]
path_openat+0x4eb/0x23a0 fs/namei.c:3550
do_filp_open+0x197/0x270 fs/namei.c:3584
do_open_execat+0x10d/0x5b0 fs/exec.c:849
do_execveat_common.isra.14+0x6cb/0x1d60 fs/exec.c:1740
do_execve fs/exec.c:1847 [inline]
SYSC_execve fs/exec.c:1928 [inline]
SyS_execve+0x34/0x40 fs/exec.c:1923
do_syscall_64+0x19b/0x4b0 arch/x86/entry/common.c:289
entry_SYSCALL_64_after_hwframe+0x42/0xb7

-> #0 (&sig->cred_guard_mutex){+.+.}:
lock_acquire+0x10f/0x380 kernel/locking/lockdep.c:3991
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0xf5/0x1480 kernel/locking/mutex.c:893
proc_pid_attr_write+0x16b/0x280 fs/proc/base.c:2590
__vfs_write+0xf4/0x5c0 fs/read_write.c:482
__kernel_write+0xf3/0x330 fs/read_write.c:503
write_pipe_buf+0x192/0x250 fs/splice.c:797
splice_from_pipe_feed fs/splice.c:502 [inline]
__splice_from_pipe+0x324/0x740 fs/splice.c:626
splice_from_pipe+0xcf/0x130 fs/splice.c:661
default_file_splice_write+0x37/0x80 fs/splice.c:809
do_splice_from fs/splice.c:851 [inline]
do_splice fs/splice.c:1147 [inline]
SYSC_splice fs/splice.c:1402 [inline]
SyS_splice+0xd06/0x12a0 fs/splice.c:1382
do_syscall_64+0x19b/0x4b0 arch/x86/entry/common.c:289
entry_SYSCALL_64_after_hwframe+0x42/0xb7

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&pipe->mutex/1);
lock(&sig->cred_guard_mutex);
lock(&pipe->mutex/1);
lock(&sig->cred_guard_mutex);

*** DEADLOCK ***

2 locks held by syz-executor134/18778:
#0: (sb_writers#7){.+.+}, at: [<ffffffff93dfe7cc>] file_start_write
include/linux/fs.h:2722 [inline]
#0: (sb_writers#7){.+.+}, at: [<ffffffff93dfe7cc>] do_splice
fs/splice.c:1146 [inline]
#0: (sb_writers#7){.+.+}, at: [<ffffffff93dfe7cc>] SYSC_splice
fs/splice.c:1402 [inline]
#0: (sb_writers#7){.+.+}, at: [<ffffffff93dfe7cc>]
SyS_splice+0xeac/0x12a0 fs/splice.c:1382
#1: (&pipe->mutex/1){+.+.}, at: [<ffffffff93d72e28>] pipe_lock_nested
fs/pipe.c:67 [inline]
#1: (&pipe->mutex/1){+.+.}, at: [<ffffffff93d72e28>] pipe_lock+0x58/0x70
fs/pipe.c:75

stack backtrace:
CPU: 1 PID: 18778 Comm: syz-executor134 Not tainted 4.14.78+ #22
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xb9/0x11b lib/dump_stack.c:53
print_circular_bug.isra.18.cold.43+0x2d3/0x40c
kernel/locking/lockdep.c:1258
check_prev_add kernel/locking/lockdep.c:1901 [inline]
check_prevs_add kernel/locking/lockdep.c:2018 [inline]
validate_chain kernel/locking/lockdep.c:2460 [inline]
__lock_acquire+0x2ff9/0x4320 kernel/locking/lockdep.c:3487
lock_acquire+0x10f/0x380 kernel/locking/lockdep.c:3991
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0xf5/0x1480 kernel/locking/mutex.c:893
proc_pid_attr_write+0x16b/0x280 fs/proc/base.c:2590
__vfs_write+0xf4/0x5c0 fs/read_write.c:482
__kernel_write+0xf3/0x330 fs/read_write.c:503
write_pipe_buf+0x192/0x250 fs/splice.c:797
splice_from_pipe_feed fs/splice.c:502 [inline]
__splice_from_pipe+0x324/0x740 fs/splice.c:626
splice_from_pipe+0xcf/0x130 fs/splice.c:661
default_file_splice_write+0x37/0x80 fs/splice.c:809
do_splice_from fs/splice.c:851 [inline]
do_splice fs/splice.c:1147 [inline]
SYSC_splice fs/splice.c:1402 [inline]
SyS_splice+0xd06/0x12a0 fs/splice.c:1382
do_syscall_64+0x19b/0x4b0 arch/x86/entry/common.c:289
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x446bf9
RSP: 002b:00007f86da0ddcd8 EFLAGS: 00000216 ORIG_RAX: 0000000000000113
RAX: ffffffffffffffda RBX: 00000000006dcc48 RCX: 0000000000446bf9
RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00000000006dcc40 R08: 0000000000000003 R09: 0000010000000000
R10: 0000000000000000 R11: 0000000000000216 R12: 00000000006dcc4c
R13: 00007ffedc67eacf R14: 00007f86da0de9c0 R15: 00000000006dcd4c


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
Reply all
Reply to author
Forward
0 new messages