| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2024102109-CVE-2024-47740-ae86@gregkh> Date: Mon, 21 Oct 2024 14:16:19 +0200 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: CVE-2024-47740: f2fs: Require FMODE_WRITE for atomic write ioctls Description =========== In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls 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. The Linux kernel CVE team has assigned CVE-2024-47740 to this issue. Affected and fixed versions =========================== Issue introduced in 3.18 with commit 88b88a667971 and fixed in 5.10.227 with commit 000bab8753ae Issue introduced in 3.18 with commit 88b88a667971 and fixed in 5.15.168 with commit 88ff021e1fea Issue introduced in 3.18 with commit 88b88a667971 and fixed in 6.1.113 with commit 32f348ecc149 Issue introduced in 3.18 with commit 88b88a667971 and fixed in 6.6.54 with commit 5e0de753bfe8 Issue introduced in 3.18 with commit 88b88a667971 and fixed in 6.10.13 with commit f3bfac2cabf5 Issue introduced in 3.18 with commit 88b88a667971 and fixed in 6.11.2 with commit 4583290898c1 Issue introduced in 3.18 with commit 88b88a667971 and fixed in 6.12-rc1 with commit 4f5a100f87f3 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2024-47740 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: fs/f2fs/file.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/000bab8753ae29a259feb339b99ee759795a48ac https://git.kernel.org/stable/c/88ff021e1fea2d9b40b2d5efd9013c89f7be04ac https://git.kernel.org/stable/c/32f348ecc149e9ca70a1c424ae8fa9b6919d2713 https://git.kernel.org/stable/c/5e0de753bfe87768ebe6744d869caa92f35e5731 https://git.kernel.org/stable/c/f3bfac2cabf5333506b263bc0c8497c95302f32d https://git.kernel.org/stable/c/4583290898c13c2c2e5eb8773886d153c2c5121d https://git.kernel.org/stable/c/4f5a100f87f32cb65d4bb1ad282a08c92f6f591e
Powered by blists - more mailing lists