linux-kernel - Re: possible deadlock in ovl_write

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]

Message-ID: <CAOQ4uxhjFjeQ6m6c84Hv9V73brMKEOFNsg3Q1Kjb3resSdDjyA@mail.gmail.com>
Date:   Tue, 27 Nov 2018 18:13:03 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     syzbot+695726bc473f9c36a4b6@...kaller.appspotmail.com,
        Miklos Szeredi <miklos@...redi.hu>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        overlayfs <linux-unionfs@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com
Subject: Re: possible deadlock in ovl_write_iter

> > This looks like a false positive because lockdep is not aware of
> > s_stack_depth of the file (fs) associated with the pipe.
>
> There must be some annotation to tell lockdep about this.
>

It's a long story that can be summed up as "not simple":
https://lkml.org/lkml/2017/9/21/63

Overlayfs annotates inode mutex in lockdep friendly manner.
This is why you see:
 (&ovl_i_mutex_key[depth]){+.+.}, at: inode_lock

But this does not extend to other locks that may be associated
with filesystem or blockdev objects (e.g. pipe_lock()) and does
not cover the case of stacked blockdev (e.g. loop).

Thanks,
Amir.