From: Al Viro <viro@zeniv.linux.org.uk>
To: Vasiliy Kovalev <kovalev@altlinux.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Amir Goldstein <amir73il@gmail.com>,
linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ovl: Add check for missing lookup operation on inode
Date: Sat, 23 Nov 2024 00:21:57 +0000 [thread overview]
Message-ID: <20241123002157.GP3387508@ZenIV> (raw)
In-Reply-To: <6fb27fea-3998-0fdf-9210-d7479baf0570@basealt.ru>
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.
prev parent reply other threads:[~2024-11-23 0:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 14:17 [PATCH] ovl: Add check for missing lookup operation on inode Vasiliy Kovalev
2024-11-18 18:54 ` Amir Goldstein
2024-11-19 9:05 ` Miklos Szeredi
2024-11-19 14:33 ` Vasiliy Kovalev
2024-11-19 15:11 ` Amir Goldstein
2024-11-19 15:58 ` [PATCH v2] ovl: Filter invalid inodes with missing lookup function Vasiliy Kovalev
2024-11-20 12:34 ` Amir Goldstein
2024-11-23 0:21 ` Al Viro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241123002157.GP3387508@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=amir73il@gmail.com \
--cc=kovalev@altlinux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox