linux-kernel - Re: INFO: task hung in lo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 20 Jan 2019 10:49:45 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Omar Sandoval <osandov@...ndov.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Omar Sandoval <osandov@...com>,
        syzbot 
        <bot+abdba5bc6de135d7622f00756da97998425b6de5@...kaller.appspotmail.com>,
        Jens Axboe <axboe@...nel.dk>, Ming Lei <tom.leiming@...il.com>,
        Hannes Reinecke <hare@...e.de>, shli@...com,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Ingo Molnar <mingo@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>, knikanth@...e.de
Subject: Re: INFO: task hung in lo_ioctl

On Sun, Jan 20, 2019 at 3:36 AM Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
>
> On 2019/01/20 3:56, Dmitry Vyukov wrote:
> >> Seems easy enough to fix without resorting to __mutex_owner() (untested):
> >>
> >>
> >> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> >> index 264abaaff662..cee258d12a1e 100644
> >> --- a/drivers/block/loop.c
> >> +++ b/drivers/block/loop.c
> >> @@ -1300,12 +1300,13 @@ loop_get_status_old(struct loop_device *lo, struct loop_info __user *arg) {
> >>  static int
> >>  loop_get_status64(struct loop_device *lo, struct loop_info64 __user *arg) {
> >>         struct loop_info64 info64;
> >> -       int err = 0;
> >> +       int err;
> >>
> >> -       if (!arg)
> >> -               err = -EINVAL;
> >> -       if (!err)
> >> -               err = loop_get_status(lo, &info64);
> >> +       if (!arg) {
> >> +               mutex_unlock(&lo->lo_ctl_mutex);
> >> +               return -EINVAL;
> >> +       }
> >> +       err = loop_get_status(lo, &info64);
> >>         if (!err && copy_to_user(arg, &info64, sizeof(info64)))
> >>                 err = -EFAULT;
> >>
> >>
> >> I'll test it and send it up when I get into the office.
> >
> >
> > Was this ever submitted? Or some other fix for this?
> >
> > The bug is still open, but last happened 289 days ago:
> > https://syzkaller.appspot.com/bug?id=608144371e7fc2cb6285b9ed871fb1eb817a61ce
> >
> > But it also has 10 duplicates, some of which happened much more recently.
> > If a fix was submitted, but Reported-by tag wasn't added this open bug
> > can now mask lots of other new bugs.
> >
>
> The commit for this specific patch is bdac616db9bbadb9 ("loop: fix LOOP_GET_STATUS
> lock imbalance"). But the root cause of these hung tasks would be fixed by a series
> containing commit 1dded9acf6dc9a34 ("Avoid circular locking dependency between
> loop_ctl_mutex and bd_mutex") or commit 04906b2f542c2362 ("blockdev: Fix livelocks
> on loop device"). We were not aware of these bugs when you marked these reports as
> duplicates on 2017/12/12. You can undup them and fix them if you want.

OK, let's just do then:

#syz fix: blockdev: Fix livelocks on loop device