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
| ||
|
Message-Id: <1901841E-AE43-4AE2-B8F0-8F745B00664F@dilger.ca>
Date: Tue, 28 Jan 2020 18:23:18 -0700
From: Andreas Dilger <adilger@...ger.ca>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-ext4 <linux-ext4@...r.kernel.org>,
Tiezhu Yang <yangtiezhu@...ngson.cn>,
"Theodore Y. Ts'o" <tytso@....edu>, Chao Yu <yuchao0@...wei.com>,
linux-fscrypt@...r.kernel.org,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup
On Jan 28, 2020, at 3:11 PM, Matthew Wilcox <willy@...radead.org> wrote:
>
>
> 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?
Maybe I'm missing something, but I think the discussion of the len == 0
case is now moot, since PATCH v6 (which is the latest version that I can
find) is checking for "len >= 1" before accessing name[0]:
+static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len)
+{
+ if (len >= 1 && unlikely(name[0] == '.')) {
+ if (len == 1 || (len == 2 && name[1] == '.'))
+ return true;
+ }
+
+ return false;
+}
This seems a tiny bit sub-optimal, as (len >= 1) is true for almost every
filename, so it doesn't allow failing the condition quickly. Checking
for exactly (len == 1) and (len == 2) allows failing this condition for
most of the files immediately, which makes "unlikely()" actually useful,
and allows simplifying the inside condition.
static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len)
{
if (unlikely((len == 1 || len == 2) && name[0] == '.')) {
if (len == 1 || name[1] == '.')
return true;
}
return false;
}
That said, this is at best micro-optimization so it isn't obvious this is
much of an improvement or not.
Cheers, Andreas
> 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 -----
Cheers, Andreas
Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)
Powered by blists - more mailing lists