From patchwork Wed Sep 25 08:16:28 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shu Han X-Patchwork-Id: 13811781 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B21CDC369AA for ; Wed, 25 Sep 2024 08:16:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 305266B007B; Wed, 25 Sep 2024 04:16:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B5276B0082; Wed, 25 Sep 2024 04:16:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17D2F6B0083; Wed, 25 Sep 2024 04:16:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E9B296B007B for ; Wed, 25 Sep 2024 04:16:46 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8FDB8AC324 for ; Wed, 25 Sep 2024 08:16:46 +0000 (UTC) X-FDA: 82602554412.05.6CF4BE6 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf09.hostedemail.com (Postfix) with ESMTP id B78B814000A for ; Wed, 25 Sep 2024 08:16:44 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UJYB9zI2; spf=pass (imf09.hostedemail.com: domain of ebpqwerty472123@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=ebpqwerty472123@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727252085; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=fRyT55ab4R2A+65MrHS5Vqlg7xItZ53sZIU1oLGBkYE=; b=MHeyJmega+ECTwCQdFEKIep1YJoI5cdPHtCTEJiDBtuB0sq7217cwEbrdXOi8x4LaNq8p8 AQsnmKuZZh+okVrljGn6ja5M+ttfNNRt3wep7RLbm09doiuQnzRWz2rCsLQjHXXgavYtJE J2buRuHtQrbxcCnn4ZsAB9InCx+K3W0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727252085; a=rsa-sha256; cv=none; b=BtRySDpCmp2WpR6WZEmbmd3edCEURs2yDNuIULUm4C8yS8nGDxtKKH3NTXH1oWACs9YZ4B SBT3K5cN7az04ikxPXo1QuaQbJ3R28BENPhHyuQJAVdllXFSGDIccE5YtxTSjaiiJdfJtX tZ2Cry61b8eeZKKVV44mFkudT6bLcXI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UJYB9zI2; spf=pass (imf09.hostedemail.com: domain of ebpqwerty472123@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=ebpqwerty472123@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-2daaa9706a9so5244392a91.1 for ; Wed, 25 Sep 2024 01:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727252203; x=1727857003; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=fRyT55ab4R2A+65MrHS5Vqlg7xItZ53sZIU1oLGBkYE=; b=UJYB9zI2bv1tzlCeO4ZqWEI1iCmcfSLK4Ctf800pyOC92WqLBkFsQhwLu4mDKoi/30 w+jeOfLFoTh2Ax5QGvGPg2Yie8d0kGlwNDf86+20ZieT4ZsufWgey5pbVq0e6dAXi4QF 3wjAL2r098wLAOfzryOQIyFg0zn9ZgC8tcFL2qWTGbVEYRqy6sp2WZOFtXf5aD2zzcnl 2miZHYEuKnZ2CLcasrjVWm3RQ+npYBT6ktsFcwc1DA2LUJsTj/YxFjFy1wFqx09fZZTN LQDbJQ0b/3pt/XwBGE0PL1ceZyY9XMfVjYiaSagj7NuPRD6cQiAteXUdgWcaOHiWVjjp pkPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727252203; x=1727857003; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fRyT55ab4R2A+65MrHS5Vqlg7xItZ53sZIU1oLGBkYE=; b=hm+ltMdmScGMNQdD9ROMZdEGJ0avH0qSXRA258PunnxnHPVkTGakHGFzANNAavEiAj kwg0RsTGAbpxyby3lBbdw0tnVv/M719yR3e0upZgyIWVaJciAbWXAFCNX38Oyv0Jl5gZ dXirT8MjJjeq2s1hz8AIrMminpKz/Kh651DrjBZxCPVAZglCxVoOZ9LtdmHu7rzArfDK QDlKxyZnHdrkOoADtxzLJCv4jjCVOjvvVxUTxlnEBH2QpSgNlQ2A18fEvlOfK5bBS0eD rrqvW9gxj3i3kKB4aU1ScF22Nl42j91jmP57QG9fXDyeBr/gu9Le6yqaYbl+YskyoTFg nTaw== X-Gm-Message-State: AOJu0YzDlYOGOIpdtURYxTAhRoHgBhYNuxsZ2myxHl9OnB9pa0DxClJp 9MIIOIRg8FJ5MbCi3Z9jz5QoOS67sqII2pHvuAn5hprVk59C5qfk X-Google-Smtp-Source: AGHT+IGZS9xjGJwPRz1ykf4pT7W+CzzPG0n3AZrZoCrp3A7RbLnNkCT0Ba3xqVKn6D1cKa5HT2lahA== X-Received: by 2002:a17:90b:2ec8:b0:2d8:9c97:3c33 with SMTP id 98e67ed59e1d1-2e06afc4197mr2134089a91.28.1727252203186; Wed, 25 Sep 2024 01:16:43 -0700 (PDT) Received: from localhost.localdomain ([20.37.103.148]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e06e2bbecasm925215a91.46.2024.09.25.01.16.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Sep 2024 01:16:42 -0700 (PDT) From: Shu Han To: akpm@linux-foundation.org, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, Liam.Howlett@oracle.com, vbabka@suse.cz, lorenzo.stoakes@oracle.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: [PATCH] mm: move security_file_mmap() back into do_mmap() Date: Wed, 25 Sep 2024 16:16:28 +0800 Message-Id: <20240925081628.408-1-ebpqwerty472123@gmail.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B78B814000A X-Stat-Signature: z43ezbp7ggywgwgsh8pcfdizsp4erf63 X-HE-Tag: 1727252204-886527 X-HE-Meta: U2FsdGVkX1/DaMxXZOBpdHa+Qqz2KmiSGC2j7b6/FgW6NVpgj5RzVueN+27MG3JmLpNjqel7XEvx6P2O++tJrYYiUlxdWsafHZw3c4PHebfzPuADqj3eX5Z34TFcays335ufQotvm+QjURC4rnFqALk3YD/AeB/zLYTrMeCAN1bSybBBl5Jfx3wC75CVGexkjhdeP5kjv072eEzPw1+4W8BImKSoOljVqUb7oAL7KEL/llnzs3hMTckvQoRvSXywkli2JTAf78KgK1I+5gVCRrkrje3EbI25qlxFHydfliGBzFrGKg22e6uUlpGnR+LLZV3OElDdlP3VNFhQXR6XvqZAia78MlYzQWvRYmaL02iBfiT443RewBjnxZEvSlYRZN9lQ4Nb8OFmQHrO74feBZ1GPG9oSYIS533snwstaQKT3/yiwUUSkxsx0ZAQk+TDtWV6dAMiUB6Xf01pVAYsz2bYTMZfCVK/6WqAj+MEtTggQfOaqFwfbvmclymuFEwDYvDT8dak41V2AAlCwHlGdNgD0VN7i2G+awpwJOsB0Z9+wDhUd75RUr+KY9DjfI81/xr6f4n8XnZfuo5dRjRrmq4S7TcHaEXmrM84F28BxVLqvi0tAunGVtrl5gfzYsb92d0i36KNXP9cvIE5ZkHEZf/sCfKS+rK6j+pJN/6QeyP1j6M917jRRzwmrn5RDOCi9SY+QzYI1gZ+1STsgwx9yGvpC6H6xzcPpCRTNsJ5kWULeR27bDbqfE19G1Yi7SoseXxmOwME5WIVDPDPtt7QK7dCsvWHleZnZQ1o3bPcOYZa0uPtdwVfBwXsEpxXlYaq/lW8lZ9bNirEKmCZsgudYDHIhaFkq7IAWBx3kBsGELizY3lLSIq5OQawOGQn1Uhn7kR+DjkxvI1mtyiSC8nNWNDw9Za3pxIWeI3TytCZbwsQ5EsGXpNo1bkKK1u+NG4tQ4zz2VbMBH+KbWiV5CP Rvy/cQmY RTBaQrjfPh+3C72o2NscC+Tq5IJNjHahspY7AVS0/A84PyNzKxaOu9F9rJSRCr8E9oB7eYxF6Jnnjf2aai+z/uhB6TC9bq+OJm4kB4A4wUFgi0T/Rh1hSHqMsYcSWsefn2/UgJh602FJT9louOd/+g44basP8rPIRLRF3AL6wltTUTbRPis3QrxwUjWsSFS1LJ6VTnf+lML6AT3UYRVbDhOVbFUU560jytBLO9IDX/rdn3GLtYw5LEW+cxbWnRuPI+agGue5ZZ6WSaMDj13Pt6roL8blpMgUY4wFNVkQUKm7soXPlVV06R3v/t+f1kjOHV2jjCrktLg926VY3cTFVIVjwXe9q3vr3M1VQ0JiRUC9RjZgjy8/8Hmcs81aP7z6TbjjwqHu95yc3aIN0b6iJSavp7QHpqyPS7gg3Zo2BB3tzE+qFoKE9KWvg9fexA/6JwrR/4ulkTi0Fs8b5/XLON1wmbbB48SY1qGNPl/ry+QrEpkOcjDUKFypciDr3/ph0F9B8VTZG3v1L8+G6WjIg3QUacg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: This patch moves the security_file_mmap() back into do_mmap(), which revert the commit 8b3ec6814c83d76b85bd13badc48552836c24839 ("take security_mmap_file() outside of ->mmap_sem"). Below is the reason. Some logic may call do_mmap() without calling security_file_mmap(), without being aware of the harm this poses to LSM. For example, CVE-2016-10044[1] has reported many years ago, but the remap_file_pages() can still bypass the W^X policy enforced by SELinux[2] for a long time. Add a check is easy, but there may have more calls to do_mmap() in the future. Moving security_file_mmap() back into do_mmap() can avoid forgetting, and avoid repeated logic for whether READ_IMPLIES_EXEC should add PROT_EXEC for the mapping or not(In current, the !MMU case won't imply exec if the file's mmap_capabilities is not exist, but the security check logic is different). It is noteworthy that moving the security check in do_mmap() will let it in the mmap_write_lock, which slows down the performance and even have deadlocks if someone depends on it(Since security_file_mprotect() is already in the lock, this possibility is tiny). Link: https://project-zero.issues.chromium.org/issues/42452389 [1] Link: https://lore.kernel.org/all/20240919080905.4506-2-paul@paul-moore.com/ [2] Signed-off-by: Shu Han --- An alternative method is moving the check of READ_IMPLIES_EXEC out of do_mmap() and calling the LSM hooks at the same time, which has better performance and compatibility but may introduce some complexity. It has been proposed in [3], which cannot be applied at the same time with this patch. Link: https://lore.kernel.org/all/20240925063034.169-1-ebpqwerty472123@gmail.com/ [3] --- include/linux/security.h | 8 ++++---- ipc/shm.c | 4 ---- mm/mmap.c | 9 +++++---- mm/nommu.c | 5 ++++- mm/util.c | 19 ++++++++----------- security/security.c | 41 ++++------------------------------------ 6 files changed, 25 insertions(+), 61 deletions(-) base-commit: f89722faa31466ff41aed21bdeb9cf34c2312858 diff --git a/include/linux/security.h b/include/linux/security.h index c37c32ebbdcd..e061bc9a0331 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -423,8 +423,8 @@ void security_file_free(struct file *file); int security_file_ioctl(struct file *file, unsigned int cmd, unsigned long arg); int security_file_ioctl_compat(struct file *file, unsigned int cmd, unsigned long arg); -int security_mmap_file(struct file *file, unsigned long prot, - unsigned long flags); +int security_mmap_file(struct file *file, unsigned long reqprot, + unsigned long prot, unsigned long flags); int security_mmap_addr(unsigned long addr); int security_file_mprotect(struct vm_area_struct *vma, unsigned long reqprot, unsigned long prot); @@ -1077,8 +1077,8 @@ static inline int security_file_ioctl_compat(struct file *file, return 0; } -static inline int security_mmap_file(struct file *file, unsigned long prot, - unsigned long flags) +static inline int security_mmap_file(struct file *file, unsigned long reqprot, + unsigned long prot, unsigned long flags) { return 0; } diff --git a/ipc/shm.c b/ipc/shm.c index 3e3071252dac..ce02560b856f 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -1636,10 +1636,6 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, sfd->vm_ops = NULL; file->private_data = sfd; - err = security_mmap_file(file, prot, flags); - if (err) - goto out_fput; - if (mmap_write_lock_killable(current->mm)) { err = -EINTR; goto out_fput; diff --git a/mm/mmap.c b/mm/mmap.c index 18fddcce03b8..56f9520f85ab 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1260,6 +1260,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, { struct mm_struct *mm = current->mm; int pkey = 0; + unsigned long reqprot = prot, err; *populate = 0; @@ -1276,6 +1277,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr, if (!(file && path_noexec(&file->f_path))) prot |= PROT_EXEC; + err = security_mmap_file(file, reqprot, prot, flags); + if (err) + return err; + /* force arch specific MAP_FIXED handling in get_unmapped_area */ if (flags & MAP_FIXED_NOREPLACE) flags |= MAP_FIXED; @@ -3198,12 +3203,8 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start, unsigned long, size, 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); diff --git a/mm/nommu.c b/mm/nommu.c index 7296e775e04e..e632f3105a5a 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -681,7 +681,7 @@ static int validate_mmap_request(struct file *file, unsigned long pgoff, unsigned long *_capabilities) { - unsigned long capabilities, rlen; + unsigned long capabilities, rlen, reqprot = prot; int ret; /* do the simple checks first */ @@ -818,6 +818,9 @@ static int validate_mmap_request(struct file *file, } /* allow the security API to have its say */ + ret = security_mmap_file(file, reqprot, prot, flags); + if (ret < 0) + return ret; ret = security_mmap_addr(addr); if (ret < 0) return ret; diff --git a/mm/util.c b/mm/util.c index bd283e2132e0..47345e927a8f 100644 --- a/mm/util.c +++ b/mm/util.c @@ -581,17 +581,14 @@ unsigned long vm_mmap_pgoff(struct file *file, unsigned long addr, unsigned long populate; LIST_HEAD(uf); - ret = security_mmap_file(file, prot, flag); - if (!ret) { - if (mmap_write_lock_killable(mm)) - return -EINTR; - ret = do_mmap(file, addr, len, prot, flag, 0, pgoff, &populate, - &uf); - mmap_write_unlock(mm); - userfaultfd_unmap_complete(mm, &uf); - if (populate) - mm_populate(ret, populate); - } + if (mmap_write_lock_killable(mm)) + return -EINTR; + ret = do_mmap(file, addr, len, prot, flag, 0, pgoff, &populate, + &uf); + mmap_write_unlock(mm); + userfaultfd_unmap_complete(mm, &uf); + if (populate) + mm_populate(ret, populate); return ret; } diff --git a/security/security.c b/security/security.c index 4564a0a1e4ef..25556629f588 100644 --- a/security/security.c +++ b/security/security.c @@ -2927,42 +2927,10 @@ int security_file_ioctl_compat(struct file *file, unsigned int cmd, } EXPORT_SYMBOL_GPL(security_file_ioctl_compat); -static inline unsigned long mmap_prot(struct file *file, unsigned long prot) -{ - /* - * Does we have PROT_READ and does the application expect - * it to imply PROT_EXEC? If not, nothing to talk about... - */ - if ((prot & (PROT_READ | PROT_EXEC)) != PROT_READ) - return prot; - if (!(current->personality & READ_IMPLIES_EXEC)) - return prot; - /* - * if that's an anonymous mapping, let it. - */ - if (!file) - return prot | PROT_EXEC; - /* - * ditto if it's not on noexec mount, except that on !MMU we need - * NOMMU_MAP_EXEC (== VM_MAYEXEC) in this case - */ - if (!path_noexec(&file->f_path)) { -#ifndef CONFIG_MMU - if (file->f_op->mmap_capabilities) { - unsigned caps = file->f_op->mmap_capabilities(file); - if (!(caps & NOMMU_MAP_EXEC)) - return prot; - } -#endif - return prot | PROT_EXEC; - } - /* anything on noexec mount won't get PROT_EXEC */ - return prot; -} - /** * security_mmap_file() - Check if mmap'ing a file is allowed * @file: file + * @reqprot: protection requested by user * @prot: protection applied by the kernel * @flags: flags * @@ -2971,11 +2939,10 @@ static inline unsigned long mmap_prot(struct file *file, unsigned long prot) * * Return: Returns 0 if permission is granted. */ -int security_mmap_file(struct file *file, unsigned long prot, - unsigned long flags) +int security_mmap_file(struct file *file, unsigned long reqprot, + unsigned long prot, unsigned long flags) { - return call_int_hook(mmap_file, file, prot, mmap_prot(file, prot), - flags); + return call_int_hook(mmap_file, file, reqprot, prot, flags); } /**