linux-kernel - Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

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]

Message-ID: <2f3d73d9-3cbc-b4c1-40ff-02bc5f440b55@huawei.com>
Date:   Thu, 12 Jan 2017 16:00:16 +0800
From:   "zhangyi (F)" <yi.zhang@...wei.com>
To:     "Theodore Ts'o" <tytso@....edu>
CC:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        <Valdis.Kletnieks@...edu>, <linux-ext4@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
        <adilger.kernel@...ger.ca>, <jack@...e.cz>,
        <viro@...iv.linux.org.uk>
Subject: Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4
 inode destroy


on 2017/1/11 23:34, Theodore Ts'o wrote:
> On Wed, Jan 11, 2017 at 05:07:29PM +0800, zhangyi (F) wrote:
>>
>> (1) The file we want to unlink have many hard links, but only one dcache entry in memory.
>> (2) open this file, but it's inode->i_nlink read from disk was 1 (too low).
>> (3) some one call rename and drop it's i_nlink to zero.
>> (4) it's inode is still in use and do not destroy (not closed), at the same time,
>>     some others open it's hard link and create a dcache entry.
>> (5) call rename again and it's i_nlink will still underflow and cause memory corruption.
> 
> Do you have reproducers that make it easy to reproduce situations like
> this?  (It shouldn't be hard to write, but if you have them already
> will save me some effort.  :-)
> 
> If we ever get passed an inode to ext4_file_open() where i_nlink is
> zero, we can declare the file system is corrupt by calling
> ext4_error() to report the problem.
> 
> Similarly, whenever we are passed a dentry pointing to an inode for
> link, unlink, rename, and other methods in the inode_operations
> structure, by definition the file system is corrupt, and again we
> should report this using ext4_error().
> 
> So I don't think we should think of this as adding "underflow
> protection"; instead we should think of it as adding more aggressive
> detection of file system inconsistencies.  If there is dentry which is
> valid, and pointing at an inode where n_links is zero, something has
> gone seriously wrong.  So we should call ext4_error() to report the
> file system inconsistency, and then return EFSCORRUPTED (aka EUCLEAN).
> 
> Since we would be doing this in a number of places, we should probably
> add an inline function:
> 
> static inline int ext4_validate_dentry(struct dentry *dentry);
> 
> which returns 0 if the dentry is valid, and calls ext4_error_inode()
> and returns -EFSCORRUPTED if the dentry points to an inode with a zero
> i_nlink.
> 

Thanks for your advice, it can detect file system inconsistency and reprot
error more effective. :-)

At the same time, I think other file systems may have the same problem, do
you think we should put these detections on the VFS layer? Thus other file
systems no need to do the same things, but the disadvantage is that we can
not call ext4_error to report ext4 inconsistency.

yi zhang