linux-kernel - Re: [PATCH] ovl: Add check for missing lookup operation on inode

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] [day] [month] [year] [list]

Message-ID: <20241123002157.GP3387508@ZenIV>
Date: Sat, 23 Nov 2024 00:21:57 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Vasiliy Kovalev <kovalev@...linux.org>
Cc: Miklos Szeredi <miklos@...redi.hu>, Amir Goldstein <amir73il@...il.com>,
	linux-unionfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ovl: Add check for missing lookup operation on inode

On Tue, Nov 19, 2024 at 05:33:03PM +0300, Vasiliy Kovalev wrote:

> without a lookup operation.  Adding the following check in bfs_iget:
> 
> struct inode *bfs_iget(struct super_block *sb, unsigned long ino)
> {
> 
> ...
> 	brelse(bh);
> 
> +	if (S_ISDIR(inode->i_mode) && !inode->i_op->lookup) {
> +		printf("Directory inode missing lookup %s:%08lx\n",
> 						inode->i_sb->s_id, ino);
> +		goto error;
> +	}
> +
> 	unlock_new_inode(inode);
> 	return inode;
> 
> error:
> 	iget_failed(inode);
> 	return ERR_PTR(-EIO);
> }
> 
> prevents the error but exposes an invalid inode:
> 
> loop0: detected capacity change from 0 to 64
> BFS-fs: bfs_iget(): Directory inode missing lookup loop0:00000002
> overlayfs: overlapping lowerdir path
> 
> Would this be considered a valid workaround, or does BFS require further
> fixes?

Yes, it does.  Note that this
        inode->i_mode = 0x0000FFFF & le32_to_cpu(di->i_mode);
sets the bits 0..15, which includes not only the permissions
(0..11), but the file type as well.  And those |= are not
going to be enough to prevent trouble - what we have there
is
	0x1000 => FIFO
	0x2000 => CHR
	0x4000 => DIR
	0x6000 => BLK
	0x8000 => REG
	0xa000 => LNK
	0xe000 => SOCK

So depending upon ->i_vtype you get one of
	* ->i_op and ->i_fop set for directory, type bits - 0x4000 | junk
	* ->i_op and ->i_fop set for regular file, type bits - 0x8000 | junk
	* ->i_op and ->i_fop left empty, type bits - junk.

Frankly, I would rather ignore bits 12..15 (i.e.
        inode->i_mode = 0x00000FFF & le32_to_cpu(di->i_mode);
instead of
        inode->i_mode = 0x0000FFFF & le32_to_cpu(di->i_mode);
) and complain (and fail) if ->i_vtype value is fucked up.