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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.