[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200128221112.GA30200@bombadil.infradead.org>
Date: Tue, 28 Jan 2020 14:11:12 -0800
From: Matthew Wilcox <willy@...radead.org>
To: linux-ext4@...r.kernel.org,
Andreas Dilger <adilger.kernel@...ger.ca>
Subject: [willy@...radead.org: Re: [willy@...radead.org: Re: [PATCH v4] fs:
introduce is_dot_or_dotdot helper for cleanup]]
I've tried to get Ted's opinion on this a few times with radio silence.
Or email is broken. Anyone else care to offer an opinion?
----- Forwarded message from Matthew Wilcox <willy@...radead.org> -----
Date: Thu, 23 Jan 2020 21:11:43 -0800
From: Matthew Wilcox <willy@...radead.org>
To: "Theodore Y. Ts'o" <tytso@....edu>
Subject: Re: [willy@...radead.org: Re: [PATCH v4] fs: introduce
is_dot_or_dotdot helper for cleanup]
ping?
On Mon, Dec 30, 2019 at 06:13:03AM -0800, Matthew Wilcox wrote:
>
> Didn't see a response from you on this. Can you confirm the three
> cases in ext4 mentioned below should be converted to return -EUNCLEAN?
>
> ----- Forwarded message from Matthew Wilcox <willy@...radead.org> -----
>
> Date: Thu, 12 Dec 2019 10:13:02 -0800
> From: Matthew Wilcox <willy@...radead.org>
> To: Eric Biggers <ebiggers@...nel.org>
> Cc: Tiezhu Yang <yangtiezhu@...ngson.cn>, Alexander Viro
> <viro@...iv.linux.org.uk>, "Theodore Y. Ts'o" <tytso@....edu>, Jaegeuk
> Kim <jaegeuk@...nel.org>, Chao Yu <yuchao0@...wei.com>, Tyler Hicks
> <tyhicks@...onical.com>, linux-fsdevel@...r.kernel.org,
> ecryptfs@...r.kernel.org, linux-fscrypt@...r.kernel.org,
> linux-f2fs-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup
> User-Agent: Mutt/1.12.1 (2019-06-15)
>
> On Tue, Dec 10, 2019 at 11:19:13AM -0800, Eric Biggers wrote:
> > > +static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len)
> > > +{
> > > + if (unlikely(name[0] == '.')) {
> > > + if (len < 2 || (len == 2 && name[1] == '.'))
> > > + return true;
> > > + }
> > > +
> > > + return false;
> > > +}
> >
> > This doesn't handle the len=0 case. Did you check that none of the users pass
> > in zero-length names? It looks like fscrypt_fname_disk_to_usr() can, if the
> > directory entry on-disk has a zero-length name. Currently it will return
> > -EUCLEAN in that case, but with this patch it may think it's the name ".".
>
> Trying to wrench this back on track ...
>
> fscrypt_fname_disk_to_usr is called by:
>
> fscrypt_get_symlink():
> if (cstr.len == 0)
> return ERR_PTR(-EUCLEAN);
> ext4_readdir():
> Does not currently check de->name_len. I believe this check should
> be added to __ext4_check_dir_entry() because a zero-length directory
> entry can affect both encrypted and non-encrypted directory entries.
> dx_show_leaf():
> Same as ext4_readdir(). Should probably call ext4_check_dir_entry()?
> htree_dirblock_to_tree():
> Would be covered by a fix to ext4_check_dir_entry().
> f2fs_fill_dentries():
> if (de->name_len == 0) {
> ...
> ubifs_readdir():
> Does not currently check de->name_len. Also affects non-encrypted
> directory entries.
>
> So of the six callers, two of them already check the dirent length for
> being zero, and four of them ought to anyway, but don't. I think they
> should be fixed, but clearly we don't historically check for this kind
> of data corruption (strangely), so I don't think that's a reason to hold
> up this patch until the individual filesystems are fixed.
>
> ----- End forwarded message -----
----- End forwarded message -----
Powered by blists - more mailing lists