linux-kernel - Re: [syzbot] WARNING in mntput_no

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]

Date:   Wed, 18 May 2022 04:38:53 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     syzbot <syzbot+5b1e53987f858500ec00@...kaller.appspotmail.com>
Cc:     hdanton@...a.com, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] WARNING in mntput_no_expire (3)

On Wed, May 18, 2022 at 01:58:40AM +0000, Al Viro wrote:
> On Wed, May 18, 2022 at 01:10:20AM +0000, Al Viro wrote:
> > On Wed, May 18, 2022 at 12:59:46AM +0000, Al Viro wrote:
> > > On Tue, May 17, 2022 at 10:58:15PM +0000, Al Viro wrote:
> > > > On Tue, May 17, 2022 at 03:49:07PM -0700, syzbot wrote:
> > > > > Hello,
> > > > > 
> > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > > > WARNING in mntput_no_expire
> > > > 
> > > > Obvious question: which filesystem it is?
> > > 
> > > FWIW, can't reproduce here - at least not with C reproducer +
> > > -rc7^ kernel + .config from report + debian kvm image (bullseye,
> > > with systemd shite replaced with sysvinit, which might be relevant).
> > > 
> > > In case systemd-specific braindamage is needed to reproduce it...
> > > Hell knows; at least mount --make-rshared / doesn't seem to suffice.
> > 
> > ... doesn't reproduce with genuine systemd either.  FWIW, 4-way SMP
> > setup here.
> 
> OK, reproduced...

FWIW, it smells like something (cgroup?) fucking up percpu allocation/freeing.
Note that struct mount has both refcount and writers count held in percpu;
replacing the refcount with atomic_t gets rid of seeing negative refcount
in mntput_no_expire(), but leaves negative writers count caught in
cleanup_mnt(); turn that from WARN_ON into printk and we get past that,
only to see
	percpu ref (css_release) <= 0 (-4294967294)
immediately afterwards.

IOW, it looks like we are getting not messed refcounting on either side,
but same refcount physically shared by unrelated objects.