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 PHC | |
Open Source and information security mailing list archives
| ||
|
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