linux-kernel - Re: [PATCH v16 04/10] fs/ntfs3: Add file operations and implementation

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 27 Dec 2020 11:59:11 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
Cc:     linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
        linux-kernel@...r.kernel.org, pali@...nel.org, dsterba@...e.cz,
        aaptel@...e.com, rdunlap@...radead.org, joe@...ches.com,
        mark@...mstone.com, nborisov@...e.com,
        linux-ntfs-dev@...ts.sourceforge.net, anton@...era.com,
        dan.carpenter@...cle.com, hch@....de, ebiggers@...nel.org
Subject: Re: [PATCH v16 04/10] fs/ntfs3: Add file operations and
 implementation

On Fri, Dec 25, 2020 at 04:51:13PM +0300, Konstantin Komarov wrote:
> +static int ntfs_readdir(struct file *file, struct dir_context *ctx)
> +{
> +	const struct INDEX_ROOT *root;
> +	u64 vbo;
> +	size_t bit;
> +	loff_t eod;
> +	int err = 0;
> +	struct inode *dir = file_inode(file);
> +	struct ntfs_inode *ni = ntfs_i(dir);
> +	struct super_block *sb = dir->i_sb;
> +	struct ntfs_sb_info *sbi = sb->s_fs_info;
> +	loff_t i_size = dir->i_size;

I appreciate directories are never likely to exceed 4GB, but why not
use i_size_read() here?

> +	u32 pos = ctx->pos;
> +	u8 *name = NULL;
> +	struct indx_node *node = NULL;
> +	u8 index_bits = ni->dir.index_bits;
> +
> +	/* name is a buffer of PATH_MAX length */
> +	static_assert(NTFS_NAME_LEN * 4 < PATH_MAX);
> +
> +	if (ni->dir.changed) {
> +		ni->dir.changed = false;
> +		pos = 0;
> +	}

I don't think that 'changed' as implemented is all that useful.  If you
have one reader and one-or-more writers, the reader will go back to the
start, but if you have two readers and one-or-more writers, only one
reader will see the 'changed' flag before the other one resets it.

You need to use a sequence counter or something if you want this to be
proof against multiple readers, and honestly I don't think it's worth it.
POSIX says:
: If a file is removed from or added to the directory after the most
: recent call to opendir() or rewinddir(), whether a subsequent call to
: readdir() returns an entry for that file is unspecified.

> +	eod = i_size + sbi->record_size;
> +
> +	if (pos >= eod)
> +		return 0;
> +
> +	if (!dir_emit_dots(file, ctx))
> +		return 0;
> +
> +	/* allocate PATH_MAX bytes */
> +	name = __getname();
> +	if (!name)
> +		return -ENOMEM;
> +
> +	ni_lock(ni);

What is ni_lock() protecting against here?  You're being called under the
protection of dir->i_rwsem, which excludes simultaneous calls to create,
link, mknod, symlink, mkdir, unlink, rmdir and rename.

> +const struct file_operations ntfs_dir_operations = {
> +	.llseek = generic_file_llseek,
> +	.read = generic_read_dir,
> +	.iterate = ntfs_readdir,

This should probably be iterate_shared so multiple calls to readdir can
be in progress at once (see Documentation/filesystems/porting)