On Mon, Apr 07, 2025 at 08:19:25AM -0400, Jeff Layton wrote:
On Mon, 2025-04-07 at 11:54 +0200, Christian Brauner wrote:
This allows the VFS to not trip over anonymous inodes and we can add asserts based on the mode into the vfs. When we report it to userspace we can simply hide the mode to avoid regressions. I've audited all direct callers of alloc_anon_inode() and only secretmen overrides i_mode and i_op inode operations but it already uses a regular file.
Fixes: af153bb63a336 ("vfs: catch invalid modes in may_open()") Cc: stable@vger.kernel.org # all LTS kernels Reported-by: syzbot+5d8e79d323a13aa0b248@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67ed3fb3.050a0220.14623d.0009.GAE@google.com Signed-off-by: Christian Brauner brauner@kernel.org
fs/anon_inodes.c | 36 ++++++++++++++++++++++++++++++++++++ fs/internal.h | 3 +++ fs/libfs.c | 2 +- 3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c index 583ac81669c2..42e4b9c34f89 100644 --- a/fs/anon_inodes.c +++ b/fs/anon_inodes.c @@ -24,9 +24,43 @@ #include <linux/uaccess.h> +#include "internal.h"
static struct vfsmount *anon_inode_mnt __ro_after_init; static struct inode *anon_inode_inode __ro_after_init; +/*
- User space expects anonymous inodes to have no file type in st_mode.
Weird. Does anything actually depend on this?
Yeah, lsof failed and started complaining about this. They're checking the mode to recognize anonymous inodes. And tbf, it works to generically recognizer proper anonymous inodes because they came come from very different superblocks (dmabuf, drm, vfio, anon_inode_mnt etc.).
ISTM that they should report a file type.
I agree but that ship has probably sailed.