@@ -514,6 +514,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
struct core_name cn;
struct mm_struct *mm = current->mm;
struct linux_binfmt * binfmt;
+ struct inode *pwd_inode;
const struct cred *old_cred;
struct cred *cred;
int retval = 0;
@@ -559,6 +560,20 @@ void do_coredump(const kernel_siginfo_t *siginfo)
need_suid_safe = true;
}
+ /*
+ * If we are a set-uid/gid root process and the current directory is
+ * owned by root but not universally writable, prohibit dumps under
+ * this path.
+ *
+ * Mitigate https://www.openwall.com/lists/oss-security/2021/10/20/2
+ */
+ pwd_inode = current->fs->pwd.dentry->d_inode;
+ if (current->flags & PF_SUID &&
+ capable(CAP_SYS_ADMIN) &&
+ uid_eq(pwd_inode->i_uid, GLOBAL_ROOT_UID) &&
+ !(pwd_inode->i_mode & 0002))
+ need_suid_safe = true;
+
retval = coredump_wait(siginfo->si_signo, &core_state);
if (retval < 0)
goto fail_creds;
A set-uid executable might be a vector to a privilege escalation if the system configures the coredump file name pattern as a relative directory destiny. The full description of the vulnerability and a demonstration of how we can exploit it can be found at [1]. We now check if the core dump pattern is relative. If it is, then we verify if root owns the current directory and if it does, we deny writing the core file unless the directory is universally writable. [1] https://www.openwall.com/lists/oss-security/2021/10/20/2 Signed-off-by: Wander Lairson Costa <wander@redhat.com> --- fs/coredump.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)