linux-kernel - Re: [syzbot] [reiserfs?] possible deadlock in reiserfs_dirty

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, 08 Nov 2023 09:00:38 +0100
From:   Roberto Sassu <roberto.sassu@...weicloud.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     syzbot <syzbot+c319bb5b1014113a92cf@...kaller.appspotmail.com>,
        jack@...e.cz, jeffm@...e.com, hdanton@...a.com,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        reiserfs-devel@...r.kernel.org, roberto.sassu@...wei.com,
        syzkaller-bugs@...glegroups.com, syzkaller@...glegroups.com,
        linux-security-module@...r.kernel.org
Subject: Re: [syzbot] [reiserfs?] possible deadlock in reiserfs_dirty_inode

On Tue, 2023-11-07 at 17:26 -0500, Paul Moore wrote:
> On Tue, Nov 7, 2023 at 6:03 AM Roberto Sassu
> <roberto.sassu@...weicloud.com> wrote:
> > On Mon, 2023-11-06 at 17:53 -0500, Paul Moore wrote:
> > > Hi Roberto,
> > > 
> > > I know you were looking at this over the summer[1], did you ever find
> > > a resolution to this?  If not, what do you think of just dropping
> > > security xattr support on reiserfs?  Normally that wouldn't be
> > > something we could consider, but given the likelihood that this hadn't
> > > been working in *years* (if ever), and reiserfs is deprecated, I think
> > > this is a viable option if there isn't an obvious fix.
> > > 
> > > [1] https://lore.kernel.org/linux-security-module/CAHC9VhTM0a7jnhxpCyonepcfWbnG-OJbbLpjQi68gL2GVnKSRg@mail.gmail.com/
> > 
> > Hi Paul
> > 
> > at the time, I did some investigation and came with a patch that
> > (likely) solves some of the problems:
> > 
> > https://lore.kernel.org/linux-fsdevel/4aa799a0b87d4e2ecf3fa74079402074dc42b3c5.camel@huaweicloud.com/#t
> 
> Ah, thanks for the link, it looks like that was swallowed by my inbox.
> In general if you feel it is worth adding my email to a patch, you
> should probably also CC the LSM list.  If nothing else there is a
> patchwork watching the LSM list that I use to make sure I don't
> miss/forget about patches.
> 
> > I did a more advanced patch (to be validated), trying to fix the root
> > cause:
> > 
> > https://lore.kernel.org/linux-fsdevel/ffde7908-be73-cc56-2646-72f4f94cb51b@huaweicloud.com/
> > 
> > However, Jeff Mahoney (that did a lot of work in this area) suggested
> > that maybe we should not try invasive changes, as anyway reiserfs will
> > be removed from the kernel in 2025.
> 
> I tend to agree with Jeff, which is one of the reasons I was
> suggesting simply removing LSM xattr support from reiserfs, although
> depending on what that involves it might be a big enough change that
> we are better off simply leaving it broken.  I think we need to see
> what that patch would look like first.
> 
> > It wouldn't be a problem to move the first patch forward.
> 
> I worry that the first patch you mentioned above doesn't really solve
> anything, it only makes it the responsibility of the user to choose
> either A) a broken system where LSM xattrs don't work or B) a system
> that will likely deadlock/panic.  I think I would rather revert the
> original commit and just leave the LSM xattrs broken than ask a user
> to make that choice.

Ok, that would be fine for me.

Thanks

Roberto