linux-kernel - Re: kernel BUG in block

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: <YV+7eslze4LhMSWp@casper.infradead.org>
Date:   Fri, 8 Oct 2021 04:31:06 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Hao Sun <sunhao.th@...il.com>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
        linux-block@...r.kernel.org, Yang Shi <shy828301@...il.com>
Subject: Re: kernel BUG in block_invalidatepage

On Fri, Oct 08, 2021 at 11:02:14AM +0800, Hao Sun wrote:
> Matthew Wilcox <willy@...radead.org> 于2021年10月7日周四 下午10:20写道：
> >
> > On Thu, Oct 07, 2021 at 02:40:29PM +0800, Hao Sun wrote:
> > > Hello,
> > >
> > > This crash can still be triggered repeatedly on the latest kernel.
> >
> > I asked you three days ago to try a patch and report the results:
> >
> > https://lore.kernel.org/linux-mm/YVtWhVNFhLbA9+Tl@casper.infradead.org/
> 
> Sorry, I missed that.
> 
> Here are the results.
> Used reproducer: https://paste.ubuntu.com/p/yrYsn4zpcn/
> Kernel log *before* applying the patch: https://paste.ubuntu.com/p/WtkFKB6Vy9/
> Kernel log *after* applying the patch: https://paste.ubuntu.com/p/S2VrtDdggp/
> Symbolized log: https://paste.ubuntu.com/p/RwXjCXDxB8/

OK, so that's ioctl(fd, BLKRRPART).  That reproducer is a beast, and I
can't help but think it could be minimised.

I think I see what's going on here though.  We open a block device, mount
some stuff on it.  khugepaged comes through and decides to create a THP
for some of the pages on it.  Nobody has it open for write, so why not?
But then the filesystem on top of it dirties something -- it doesn't
need to go through an open file descriptor because it's a filesystem.
So when we call BLKRRPART, it tries to write the dirty things back
(which it should) and things go wrong because the writeback path is not
equipped to handle compound pages.

So, yeah, let's do what Yang Shi suggested and tell khugepaged to never
try to work on block devices.  I can't think how any of this could happen
except to a block device, so there's no more insight to be gained here.