In the Linux kernel, the following vulnerability has been resolved:f2fs: Require FMODE_WRITE for atomic write ioctlsThe F2FS ioctls for starting and committing atomic writes check forinode_owner_or_capable(), but this does not give LSMs like SELinux orLandlock an opportunity to deny the write access - if the caller's FSUIDmatches the inode's UID, inode_owner_or_capable() immediately returns true.There are scenarios where LSMs want to deny a process the ability to writeparticular files, even files that the FSUID of the process owns; but thiscan 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 fileFix it by requiring FMODE_WRITE for these operations, just like forF2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using theseioctls when intending to write into the file, that seems unlikely to breakanything.
No PoCs from references.
- https://github.com/w4zu/Debian_security