linux-kernel - Re: Patch for a overwriting/corruption of the file system

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: <20230421030530.GB3390869@ZenIV>
Date:   Fri, 21 Apr 2023 04:05:30 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Kirtikumar Anandrao Ramchandani <kirtiar15502@...il.com>
Cc:     Christian Brauner <brauner@...nel.org>,
        "cc: Greg KH" <gregkh@...uxfoundation.org>, security@...nel.org,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Linus Torvalds <torvalds@...uxfoundation.org>
Subject: Re: Patch for a overwriting/corruption of the file system

On Fri, Apr 21, 2023 at 04:00:17AM +0100, Al Viro wrote:
> On Wed, Mar 15, 2023 at 02:33:48PM +0530, Kirtikumar Anandrao Ramchandani wrote:
> > While I am going through the code at the moment, I think there is one more
> > issue. It probably can't just compare "old_dir" and "new_dir", since those
> > are just pointers to structs. So, both addresses can be completely
> > different, and still represent the same folder, yes?
> 
> No, they can not.  We should never have different in-core instances of
> struct inode representing the same on-disk object - otherwise all locking
> goes to hell, for example.

... and we should never, ever have two dentries aliasing the same directory
inode, so d_inode() part is also not needed and actively confusing,
since anyone running into it is likely to go "Why is it written that way?
What is it protecting against?  Where does <such and such code> protect
itself against the same situation?".  And there's a _lot_ of code that
would break horribly if we ever run into such.

Defensive programming can be harmful...