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  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:   Mon, 27 Feb 2017 18:27:55 +0000
From:   Al Viro <>
To:     Dmitry Vyukov <>
Cc:     "" <>,
        LKML <>, Jens Axboe <>,
        Andrew Morton <>,
        Tejun Heo <>, Jan Kara <>,
        Johannes Weiner <>,
        "" <>,
        Andrey Ryabinin <>,
        syzkaller <>
Subject: Re: mm: GPF in bdi_put

On Mon, Feb 27, 2017 at 06:11:11PM +0100, Dmitry Vyukov wrote:
> Hello,
> The following program triggers GPF in bdi_put:

What happens is
	* attempt of, essentially, mount -t bdev ..., calls mount_pseudo()
and then promptly destroys the new instance it has created.
	* the only inode created on that sucker (root directory, that
is) gets evicted.
	* most of ->evict_inode() is harmless, until it gets to
        if (bdev->bd_bdi != &noop_backing_dev_info)

added there by "block: Make blk_get_backing_dev_info() safe without open bdev".
Since ->bd_bdi hadn't been initialized for that sucker (the same patch has
placed initialization into bdget()), we step into shit of varying nastiness,
depending on phase of moon, etc.

Could somebody explain WTF do we have those two lines in bdev_evict_inode(),
anyway?  We set ->bd_bdi to something other than noop_backing_dev_info only
in __blkdev_get() when ->bd_openers goes from zero to positive, so why is
the matching bdi_put() not in __blkdev_put()?  Jan?

Powered by blists - more mailing lists