From: Jann Horn jannh@google.com
commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true.
There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways:
- F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file
Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.
Fixes: 88b88a667971 ("f2fs: support atomic writes") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn jannh@google.com Reviewed-by: Chao Yu chao@kernel.org Reviewed-by: Eric Biggers ebiggers@google.com Signed-off-by: Jaegeuk Kim jaegeuk@kernel.org Signed-off-by: Eric Biggers ebiggers@google.com --- fs/f2fs/file.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 62f2521cd955e..2982cc5b37d78 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -2103,10 +2103,13 @@ static int f2fs_ioc_start_atomic_write(struct file *filp) struct f2fs_sb_info *sbi = F2FS_I_SB(inode); struct inode *pinode; loff_t isize; int ret;
+ if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(mnt_userns, inode)) return -EACCES;
if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -2200,10 +2203,13 @@ static int f2fs_ioc_commit_atomic_write(struct file *filp) { struct inode *inode = file_inode(filp); struct user_namespace *mnt_userns = file_mnt_user_ns(filp); int ret;
+ if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(mnt_userns, inode)) return -EACCES;
ret = mnt_want_write_file(filp); if (ret) @@ -2232,10 +2238,13 @@ static int f2fs_ioc_abort_atomic_write(struct file *filp) { struct inode *inode = file_inode(filp); struct user_namespace *mnt_userns = file_mnt_user_ns(filp); int ret;
+ if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(mnt_userns, inode)) return -EACCES;
ret = mnt_want_write_file(filp); if (ret)
base-commit: aa4cd140bba57b7064b4c7a7141bebd336d32087
On Fri, Oct 04, 2024 at 07:34:41PM +0000, Eric Biggers wrote:
From: Jann Horn jannh@google.com
commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true.
There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways:
- F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0
- F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file
Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.
Fixes: 88b88a667971 ("f2fs: support atomic writes") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn jannh@google.com Reviewed-by: Chao Yu chao@kernel.org Reviewed-by: Eric Biggers ebiggers@google.com Signed-off-by: Jaegeuk Kim jaegeuk@kernel.org Signed-off-by: Eric Biggers ebiggers@google.com
I've queued these backports, thanks!
linux-stable-mirror@lists.linaro.org