From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A599C18BC36; Wed, 19 Mar 2025 14:40:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742395255; cv=none; b=D/AWNQMTyfKVvRjjvsTCUQkCgx9JvG57W0OynqPEEclZ4WR50a78iHZDuNmncJHJ0BZawVe99jnnPzsxUA0oqyKXzE01VR7w4dHbZThnNa+C9mM5FJ2e0ghE3FJJn4tVVBg6iE+EOz9y+i1Wh5iamWreD7OpTgT+7oshty2O+lg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742395255; c=relaxed/simple; bh=C9SsyNzc5D7dyoyBYlIeJgXCLydxGXhI+8g9gjc7pcE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GUOkGNpp0143KxtMl/h/FFWFxgyLJptpwigJBYuRmOBxsYiDQzafNGbHj5/Auuws5rVK2oyxdMR3X0qkF9vg+FoTMDCRpfdC7tsXESJEGanr6fV4FI8sGGGK1hxbRK4Rot9xau0Ec3KVeK3IejF21+yzIuyBmc/iF0iDMJk/TyA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=mGtf307u; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="mGtf307u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 703BAC4CEE8; Wed, 19 Mar 2025 14:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1742395255; bh=C9SsyNzc5D7dyoyBYlIeJgXCLydxGXhI+8g9gjc7pcE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mGtf307uoN9xA0ZUmamnQ3ZafMBkMkmKNIkx27neQ1VqlQxvoV788/f2zqvW/RF3f lPCFyIYZtcgagv45bezmFVnWiMCrOMCqQs00lCwx8HgfUdS8BGE10tM0imlHPW2JAz OvCUUKBJzdAqgFUXTH5P4p2zwnnrw2/TxFuNNlTY= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Kirill A. Shutemov" , Roberto Sassu , syzbot+1cd571a672400ef3a930@syzkaller.appspotmail.com, Jann Horn , Lorenzo Stoakes , "Liam R. Howlett" , Paul Moore , Jarkko Sakkinen , Dmitry Kasatkin , Eric Snowberg , James Morris , Mimi Zohar , "Serge E. Hallyn" , Shu Han , Vlastimil Babka , Andrew Morton , Jianqi Ren , He Zhe Subject: [PATCH 6.6 138/166] mm: split critical region in remap_file_pages() and invoke LSMs in between Date: Wed, 19 Mar 2025 07:31:49 -0700 Message-ID: <20250319143023.755578926@linuxfoundation.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250319143019.983527953@linuxfoundation.org> References: <20250319143019.983527953@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.6-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kirill A. Shutemov commit 58a039e679fe72bd0efa8b2abe669a7914bb4429 upstream. Commit ea7e2d5e49c0 ("mm: call the security_mmap_file() LSM hook in remap_file_pages()") fixed a security issue, it added an LSM check when trying to remap file pages, so that LSMs have the opportunity to evaluate such action like for other memory operations such as mmap() and mprotect(). However, that commit called security_mmap_file() inside the mmap_lock lock, while the other calls do it before taking the lock, after commit 8b3ec6814c83 ("take security_mmap_file() outside of ->mmap_sem"). This caused lock inversion issue with IMA which was taking the mmap_lock and i_mutex lock in the opposite way when the remap_file_pages() system call was called. Solve the issue by splitting the critical region in remap_file_pages() in two regions: the first takes a read lock of mmap_lock, retrieves the VMA and the file descriptor associated, and calculates the 'prot' and 'flags' variables; the second takes a write lock on mmap_lock, checks that the VMA flags and the VMA file descriptor are the same as the ones obtained in the first critical region (otherwise the system call fails), and calls do_mmap(). In between, after releasing the read lock and before taking the write lock, call security_mmap_file(), and solve the lock inversion issue. Link: https://lkml.kernel.org/r/20241018161415.3845146-1-roberto.sassu@huaweicloud.com Fixes: ea7e2d5e49c0 ("mm: call the security_mmap_file() LSM hook in remap_file_pages()") Signed-off-by: Kirill A. Shutemov Signed-off-by: Roberto Sassu Reported-by: syzbot+1cd571a672400ef3a930@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-security-module/66f7b10e.050a0220.46d20.0036.GAE@google.com/ Tested-by: Roberto Sassu Reviewed-by: Roberto Sassu Reviewed-by: Jann Horn Reviewed-by: Lorenzo Stoakes Reviewed-by: Liam R. Howlett Reviewed-by: Paul Moore Tested-by: syzbot+1cd571a672400ef3a930@syzkaller.appspotmail.com Cc: Jarkko Sakkinen Cc: Dmitry Kasatkin Cc: Eric Snowberg Cc: James Morris Cc: Mimi Zohar Cc: "Serge E. Hallyn" Cc: Shu Han Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Jianqi Ren Signed-off-by: He Zhe Signed-off-by: Greg Kroah-Hartman --- mm/mmap.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 52 insertions(+), 17 deletions(-) --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2981,6 +2981,7 @@ SYSCALL_DEFINE5(remap_file_pages, unsign unsigned long populate = 0; unsigned long ret = -EINVAL; struct file *file; + vm_flags_t vm_flags; pr_warn_once("%s (%d) uses deprecated remap_file_pages() syscall. See Documentation/mm/remap_file_pages.rst.\n", current->comm, current->pid); @@ -2997,12 +2998,60 @@ SYSCALL_DEFINE5(remap_file_pages, unsign if (pgoff + (size >> PAGE_SHIFT) < pgoff) return ret; - if (mmap_write_lock_killable(mm)) + if (mmap_read_lock_killable(mm)) return -EINTR; + /* + * Look up VMA under read lock first so we can perform the security + * without holding locks (which can be problematic). We reacquire a + * write lock later and check nothing changed underneath us. + */ vma = vma_lookup(mm, start); - if (!vma || !(vma->vm_flags & VM_SHARED)) + if (!vma || !(vma->vm_flags & VM_SHARED)) { + mmap_read_unlock(mm); + return -EINVAL; + } + + prot |= vma->vm_flags & VM_READ ? PROT_READ : 0; + prot |= vma->vm_flags & VM_WRITE ? PROT_WRITE : 0; + prot |= vma->vm_flags & VM_EXEC ? PROT_EXEC : 0; + + flags &= MAP_NONBLOCK; + flags |= MAP_SHARED | MAP_FIXED | MAP_POPULATE; + if (vma->vm_flags & VM_LOCKED) + flags |= MAP_LOCKED; + + /* Save vm_flags used to calculate prot and flags, and recheck later. */ + vm_flags = vma->vm_flags; + file = get_file(vma->vm_file); + + mmap_read_unlock(mm); + + /* Call outside mmap_lock to be consistent with other callers. */ + ret = security_mmap_file(file, prot, flags); + if (ret) { + fput(file); + return ret; + } + + ret = -EINVAL; + + /* OK security check passed, take write lock + let it rip. */ + if (mmap_write_lock_killable(mm)) { + fput(file); + return -EINTR; + } + + vma = vma_lookup(mm, start); + + if (!vma) + goto out; + + /* Make sure things didn't change under us. */ + if (vma->vm_flags != vm_flags) + goto out; + if (vma->vm_file != file) goto out; if (start + size > vma->vm_end) { @@ -3030,25 +3079,11 @@ SYSCALL_DEFINE5(remap_file_pages, unsign goto out; } - prot |= vma->vm_flags & VM_READ ? PROT_READ : 0; - prot |= vma->vm_flags & VM_WRITE ? PROT_WRITE : 0; - prot |= vma->vm_flags & VM_EXEC ? PROT_EXEC : 0; - - flags &= MAP_NONBLOCK; - flags |= MAP_SHARED | MAP_FIXED | MAP_POPULATE; - if (vma->vm_flags & VM_LOCKED) - flags |= MAP_LOCKED; - - file = get_file(vma->vm_file); - ret = security_mmap_file(vma->vm_file, prot, flags); - if (ret) - goto out_fput; ret = do_mmap(vma->vm_file, start, size, prot, flags, 0, pgoff, &populate, NULL); -out_fput: - fput(file); out: mmap_write_unlock(mm); + fput(file); if (populate) mm_populate(ret, populate); if (!IS_ERR_VALUE(ret))