linux-kernel - Re: [BUG] fs/super: a possible sleep-in-atomic bug in put

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171007170651.GR21978@ZenIV.linux.org.uk>
Date:   Sat, 7 Oct 2017 18:06:51 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Vladimir Davydov <vdavydov.dev@...il.com>
Cc:     Michal Hocko <mhocko@...nel.org>,
        Jia-Ju Bai <baijiaju1990@....com>, torbjorn.lindh@...ta.se,
        rgooch@...f.csiro.au, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [BUG] fs/super: a possible sleep-in-atomic bug in put_super

On Sat, Oct 07, 2017 at 02:56:40PM +0300, Vladimir Davydov wrote:
> Hello,
> 
> On Fri, Oct 06, 2017 at 11:06:04AM +0200, Michal Hocko wrote:
> > On Fri 06-10-17 16:59:18, Jia-Ju Bai wrote:
> > > According to fs/super.c, the kernel may sleep under a spinlock.
> > > The function call path is:
> > > put_super (acquire the spinlock)
> > >   __put_super
> > >     destroy_super
> > >       list_lru_destroy
> > >         list_lru_unregister
> > >           mutex_lock --> may sleep
> > >         memcg_get_cache_ids
> > >           down_read --> may sleep
> > > 
> > > This bug is found by my static analysis tool and my code review.
> 
> This is false-positive: by the time we get to destroy_super(), the lru
> lists have already been destroyed - see deactivate_locked_super() - so
> list_lru_destroy() will retrun right away without attempting to take any
> locks. That's why there's no lockdep warnings regarding this issue.
> 
> I think we can move list_lru_destroy() to destroy_super_work() to
> suppress this warning. Not sure if it's really worth the trouble though.

It's a bit trickier than that (callers of destroy_super() prior to superblock
getting reachable via shared data structures do not have that lru_list_destroy()
a no-op, but they are not called under spinlocks).

Locking in mm/list_lru.c looks excessive, but then I'm not well familiar with
that code.