[5.15] fanotify: disallow mount/sb marks on kernel internal pseudo fs

Commit Message

Amir Goldstein July 10, 2023, 1:32 p.m. UTC

commit 69562eb0bd3e6bb8e522a7b254334e0fb30dff0c upstream.

Hopefully, nobody is trying to abuse mount/sb marks for watching all
anonymous pipes/inodes.

I cannot think of a good reason to allow this - it looks like an
oversight that dated back to the original fanotify API.

Link: https://lore.kernel.org/linux-fsdevel/20230628101132.kvchg544mczxv2pm@quack3/
Fixes: 0ff21db9fcc3 ("fanotify: hooks the fanotify_mark syscall to the vfsmount code")
Signed-off-by: Amir Goldstein <[e-mail]>
Reviewed-by: Christian Brauner <[e-mail]>
Signed-off-by: Jan Kara <[e-mail]>
Message-Id: <[e-mail]>
[backport to 5.x.y]
Signed-off-by: Amir Goldstein <[e-mail]>
---

Greg,

This 5.15 backport should cleanly apply to all 5.x.y LTS kernels.
It will NOT apply to 4.x.y kernels.

The original upstream commit should apply cleanly to 6.x.y stable
kernels.

Thanks,
Amir.

 fs/notify/fanotify/fanotify_user.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

Comments

Greg Kroah-Hartman July 16, 2023, 3:15 p.m. UTC | #1

On Mon, Jul 10, 2023 at 04:32:05PM +0300, Amir Goldstein wrote:
> commit 69562eb0bd3e6bb8e522a7b254334e0fb30dff0c upstream.
> 
> Hopefully, nobody is trying to abuse mount/sb marks for watching all
> anonymous pipes/inodes.
> 
> I cannot think of a good reason to allow this - it looks like an
> oversight that dated back to the original fanotify API.
> 
> Link: https://lore.kernel.org/linux-fsdevel/20230628101132.kvchg544mczxv2pm@quack3/
> Fixes: 0ff21db9fcc3 ("fanotify: hooks the fanotify_mark syscall to the vfsmount code")
> Signed-off-by: Amir Goldstein <[e-mail]>
> Reviewed-by: Christian Brauner <[e-mail]>
> Signed-off-by: Jan Kara <[e-mail]>
> Message-Id: <[e-mail]>
> [backport to 5.x.y]
> Signed-off-by: Amir Goldstein <[e-mail]>
> ---
> 
> Greg,
> 
> This 5.15 backport should cleanly apply to all 5.x.y LTS kernels.
> It will NOT apply to 4.x.y kernels.
> 
> The original upstream commit should apply cleanly to 6.x.y stable
> kernels.

Now queued up, thanks.

greg k-h

Patch

diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index 84ec851211d9..0e2a0eb7cb9e 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -1337,8 +1337,11 @@  static int fanotify_test_fid(struct path *path, __kernel_fsid_t *fsid)
 	return 0;
 }
 
-static int fanotify_events_supported(struct path *path, __u64 mask)
+static int fanotify_events_supported(struct path *path, __u64 mask,
+				     unsigned int flags)
 {
+	unsigned int mark_type = flags & FANOTIFY_MARK_TYPE_BITS;
+
 	/*
 	 * Some filesystems such as 'proc' acquire unusual locks when opening
 	 * files. For them fanotify permission events have high chances of
@@ -1350,6 +1353,21 @@  static int fanotify_events_supported(struct path *path, __u64 mask)
 	if (mask & FANOTIFY_PERM_EVENTS &&
 	    path->mnt->mnt_sb->s_type->fs_flags & FS_DISALLOW_NOTIFY_PERM)
 		return -EINVAL;
+
+	/*
+	 * mount and sb marks are not allowed on kernel internal pseudo fs,
+	 * like pipe_mnt, because that would subscribe to events on all the
+	 * anonynous pipes in the system.
+	 *
+	 * SB_NOUSER covers all of the internal pseudo fs whose objects are not
+	 * exposed to user's mount namespace, but there are other SB_KERNMOUNT
+	 * fs, like nsfs, debugfs, for which the value of allowing sb and mount
+	 * mark is questionable. For now we leave them alone.
+	 */
+	if (mark_type != FAN_MARK_INODE &&
+	    path->mnt->mnt_sb->s_flags & SB_NOUSER)
+		return -EINVAL;
+
 	return 0;
 }
 
@@ -1476,7 +1494,7 @@  static int do_fanotify_mark(int fanotify_fd, unsigned int flags, __u64 mask,
 		goto fput_and_out;
 
 	if (flags & FAN_MARK_ADD) {
-		ret = fanotify_events_supported(&path, mask);
+		ret = fanotify_events_supported(&path, mask, flags);
 		if (ret)
 			goto path_put_and_out;
 	}