WARNING: locking bug in loop_control_ioctl

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 442b8cea2477 Add linux-next specific files for 20181109
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14790f7b400000
kernel config: https://syzkaller.appspot.com/x/.config?x=66046c6bfaf1f24d
dashboard link: https://syzkaller.appspot.com/bug?extid=c0138741c2290fc5e63f
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15ef394d400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111cfb83400000

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

------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(depth <= 0)
WARNING: CPU: 1 PID: 5795 at kernel/locking/lockdep.c:3595 __lock_release
kernel/locking/lockdep.c:3595 [inline]
WARNING: CPU: 1 PID: 5795 at kernel/locking/lockdep.c:3595
lock_release+0x740/0xa10 kernel/locking/lockdep.c:3863
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 5795 Comm: syz-executor569 Not tainted
4.20.0-rc1-next-20181109+ #109
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x39d lib/dump_stack.c:113
panic+0x2ad/0x55c kernel/panic.c:188
__warn.cold.8+0x20/0x45 kernel/panic.c:540
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
RIP: 0010:__lock_release kernel/locking/lockdep.c:3595 [inline]
RIP: 0010:lock_release+0x740/0xa10 kernel/locking/lockdep.c:3863
Code: 03 38 d0 7c 08 84 d2 0f 85 da 02 00 00 8b 35 a7 82 b3 08 85 f6 75 15
48 c7 c6 20 66 2b 88 48 c7 c7 c0 33 2b 88 e8 10 36 e7 ff <0f> 0b 48 8b 95
e8 fe ff ff 4c 89 f7 48 8b b5 f0 fe ff ff e8 e8 58
RSP: 0018:ffff8801b9867868 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 1ffff1003730cf12 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8165ba15 RDI: 0000000000000006
RBP: ffff8801b9867998 R08: ffff8801d24940c0 R09: fffffbfff12b2254
R10: fffffbfff12b2254 R11: ffffffff895912a3 R12: ffffffff8b0e17a0
R13: ffff8801b9867970 R14: ffff8801d24940c0 R15: ffff8801b98678b0
__mutex_unlock_slowpath+0x102/0x8c0 kernel/locking/mutex.c:1197
mutex_unlock+0xd/0x10 kernel/locking/mutex.c:713
loop_control_ioctl+0xf5/0x4e0 drivers/block/loop.c:2095
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447009
Code: e8 0c b4 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fba6d10bda8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000006e19e8 RCX: 0000000000447009
RDX: 0000000000000000 RSI: 0000000000004c81 RDI: 0000000000000003
RBP: 00000000006e19e0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006e19ec
R13: 6f72746e6f632d70 R14: 6f6f6c2f7665642f R15: 00000000006e19e0
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Tetsuo Handa]

From 4b9e5556fada37dff1eff13665a229b69e1f7dd8 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
Date: Sat, 10 Nov 2018 17:04:40 +0900
Subject: [PATCH] loop: Fix double mutex_unlock(&loop_ctl_mutex) in loop_control_ioctl().

Commit 0a42e99b58a20883 ("loop: Get rid of loop_index_mutex") forgot to
remove mutex_unlock(&loop_ctl_mutex) from loop_control_ioctl() when
replacing loop_index_mutex with loop_ctl_mutex.

Reported-by: syzbot <syzbot+c01387...@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
Cc: Jan Kara <ja...@suse.cz>
---
drivers/block/loop.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index bf6bc35..176ab1f 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -2074,12 +2074,10 @@ static long loop_control_ioctl(struct file *file, unsigned int cmd,
break;
if (lo->lo_state != Lo_unbound) {
ret = -EBUSY;
- mutex_unlock(&loop_ctl_mutex);
break;
}
if (atomic_read(&lo->lo_refcnt) > 0) {
ret = -EBUSY;
- mutex_unlock(&loop_ctl_mutex);
break;
}
lo->lo_disk->private_data = NULL;
--
1.8.3.1

[Ming Lei]

Reviewed-by: Ming Lei <ming...@redhat.com>

--
Ming

[Jan Kara]

On Sat 10-11-18 17:09:09, Tetsuo Handa wrote:
> From 4b9e5556fada37dff1eff13665a229b69e1f7dd8 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
> Date: Sat, 10 Nov 2018 17:04:40 +0900
> Subject: [PATCH] loop: Fix double mutex_unlock(&loop_ctl_mutex) in loop_control_ioctl().
>
> Commit 0a42e99b58a20883 ("loop: Get rid of loop_index_mutex") forgot to
> remove mutex_unlock(&loop_ctl_mutex) from loop_control_ioctl() when
> replacing loop_index_mutex with loop_ctl_mutex.
>
> Reported-by: syzbot <syzbot+c01387...@syzkaller.appspotmail.com>
> Signed-off-by: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
> Cc: Jan Kara <ja...@suse.cz>

Yeah, my bad. Thanks for fixing this. You can add:

Reviewed-by: Jan Kara <ja...@suse.cz>

Honza

> ---
> drivers/block/loop.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index bf6bc35..176ab1f 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -2074,12 +2074,10 @@ static long loop_control_ioctl(struct file *file, unsigned int cmd,
> break;
> if (lo->lo_state != Lo_unbound) {
> ret = -EBUSY;
> - mutex_unlock(&loop_ctl_mutex);
> break;
> }
> if (atomic_read(&lo->lo_refcnt) > 0) {
> ret = -EBUSY;
> - mutex_unlock(&loop_ctl_mutex);
> break;
> }
> lo->lo_disk->private_data = NULL;
> --
> 1.8.3.1
>

--
Jan Kara <ja...@suse.com>
SUSE Labs, CR

[Tetsuo Handa]

Fix is available as commit 628bd85947091830 since next-20181113, but syzbot is
still using next-20181109. I hope we can start testing patches for loop module...

#syz fix: loop: Fix double mutex_unlock(&loop_ctl_mutex) in loop_control_ioctl()

[Dmitry Vyukov]

On Sun, Nov 25, 2018 at 2:33 PM, Tetsuo Handa
<penguin...@i-love.sakura.ne.jp> wrote:
> Fix is available as commit 628bd85947091830 since next-20181113, but syzbot is
> still using next-20181109. I hope we can start testing patches for loop module...

syzbot will start testing new code once linux-next boot is fixed:
https://groups.google.com/forum/#!msg/syzkaller-bugs/rPWi2Ry4z8I/CA-zxwCGBAAJ

[Tetsuo Handa]

On 2018/11/26 0:32, Dmitry Vyukov wrote:
> On Sun, Nov 25, 2018 at 2:33 PM, Tetsuo Handa
> <penguin...@i-love.sakura.ne.jp> wrote:
>> Fix is available as commit 628bd85947091830 since next-20181113, but syzbot is
>> still using next-20181109. I hope we can start testing patches for loop module...
>
> syzbot will start testing new code once linux-next boot is fixed:
> https://groups.google.com/forum/#!msg/syzkaller-bugs/rPWi2Ry4z8I/CA-zxwCGBAAJ

linux-next is currently failing due to "WARNING: CPU: 1 PID: 1 at net/wireless/core.c:581"
during boot, isn't it? We could temporarily fallback to "remove panic_on_warn=1 from kernel
command line" and "add 'echo 1 > /proc/sys/kernel/panic_on_warn' upon first login".

Also, as there are a lot of bugs which seem to be already fixed, regarding bugs which has
reproducers, spending some resource for "identifying which patch seems to fix the bug" would
be nice. There are bugs which are not occurring for long time but running reproducers
trivially hit the bug. Refreshing last occurrence info using resource for "identifying
which patch seems to fix the bug" would be nice.

[Dmitry Vyukov]

Agree.