CVE-2022-50014

一、漏洞信息
 漏洞编号：[CVE-2022-50014](https://nvd.nist.gov/vuln/detail/CVE-2022-50014)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：N/A None
  Vector：CVSS：3.0/
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COWEver since the Dirty COW (CVE-2016-5195) security issue happened, we knowthat FOLL_FORCE can be possibly dangerous, especially if there are racesthat can be exploited by user space.Right now, it would be sufficient to have some code that sets a PTE of aR/O-mapped shared page dirty, in order for it to erroneously becomewritable by FOLL_FORCE.  The implications of setting a write-protected PTEdirty might not be immediately obvious to everyone.And in fact ever since commit 9ae0f87d009c ( mm/shmem: unconditionally setpte dirty in mfill_atomic_install_pte ), we can use UFFDIO_CONTINUE to mapa shmem page R/O while marking the pte dirty.  This can be used byunprivileged user space to modify tmpfs/shmem file content even if theuser does not have write permissions to the file, and to bypass memfdwrite sealing -- Dirty COW restricted to tmpfs/shmem (CVE-2022-2590).To fix such security issues for good, the insight is that we really onlyneed that fancy retry logic (FOLL_COW) for COW mappings that are notwritable (!VM_WRITE).  And in a COW mapping, we really only broke COW ifwe have an exclusive anonymous page mapped.  If we have something elsemapped, or the mapped anonymous page might be shared (!PageAnonExclusive),we have to trigger a write fault to break COW.  If we don t find anexclusive anonymous page when we retry, we have to trigger COW breakingonce again because something intervened.Let s move away from this mandatory-retry + dirty handling and rely on ourPageAnonExclusive() flag for making a similar decision, to use the sameCOW logic as in other kernel parts here as well.  In case we stumble overa PTE in a COW mapping that does not map an exclusive anonymous page, COWwas not properly broken and we have to trigger a fake write-fault to breakCOW.Just like we do in can_change_pte_writable() added via commit 64fe24a3e05e( mm/mprotect: try avoiding write faults for exclusive anonymous pageswhen changing protection ) and commit 76aefad628aa ( mm/mprotect: fixsoft-dirty check in can_change_pte_writable() ), take care of softdirtyand uffd-wp manually.For example, a write() via /proc/self/mem to a uffd-wp-protected range hasto fail instead of silently granting write access and bypassing theuserspace fault handler.  Note that FOLL_FORCE is not only used for debugaccess, but also triggered by applications without debug intentions, forexample, when pinning pages via RDMA.This fixes CVE-2022-2590. Note that only x86_64 and aarch64 areaffected, because only those support CONFIG_HAVE_ARCH_USERFAULTFD_MINOR.Fortunately, FOLL_COW is no longer required to handle FOLL_FORCE. Solet s just get rid of it.Thanks to Nadav Amit for pointing out that the pte_dirty() check inFOLL_FORCE code is problematic and might be exploitable.Note 1: We don t check for the PTE being dirty because it doesn t matter	for making a  was COWed  decision anymore, and whoever modifies the	page has to set the page dirty either way.Note 2: Kernels before extended uffd-wp support and before	PageAnonExclusive (< 5.19) can simply revert the problematic	commit instead and be safe regarding UFFDIO_CONTINUE. A backport to	v5.19 requires minor adjustments due to lack of	vma_soft_dirty_enabled().
 漏洞公开时间：2025-06-18 19:15:29
 漏洞创建时间：2025-06-19 10:16:59
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2022-50014
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
|  | https://git.kernel.org/stable/c/5535be3099717646781ce1540cf725965d680e7b |  |
|  | https://git.kernel.org/stable/c/9def52eb10baab3b700858003d462fcf17d62873 |  |
|  | https://www.cve.org/CVERecord?id=CVE-2022-50014 |  |
|  | https://nvd.nist.gov/vuln/detail/CVE-2022-50014 |  |
|  | https://lore.kernel.org/linux-cve-announce/2025061833-CVE-2022-50014-2936@gregkh/T |  |
|  | https://bugzilla.redhat.com/show_bug.cgi?id=2373439 |  |
|  | https://vigilance.fr/vulnerability/Linux-kernel-multiple-vulnerabilities-dated-18-06-2025-47466 |  |

</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  七彩瞬析开源风险感知平台
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
| gregkh/linux |  | https://github.com/gregkh/linux/commit/9def52eb10baab3b700858003d462fcf17d62873.patch |  | ljqc |
|  |  | https://git.kernel.org/stable/c/5535be3099717646781ce1540cf725965d680e7b |  | nvd |
|  |  | https://git.kernel.org/stable/c/9def52eb10baab3b700858003d462fcf17d62873 |  | nvd |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COWEver since the Dirty COW (CVE-2016-5195) security issue happened, we knowthat FOLL_FORCE can be possibly dangerous, especially if there are racesthat can be exploited by user space.Right now, it would be sufficient to have some code that sets a PTE of aR/O-mapped shared page dirty, in order for it to erroneously becomewritable by FOLL_FORCE.  The implications of setting a write-protected PTEdirty might not be immediately obvious to everyone.And in fact ever since commit 9ae0f87d009c (&#34;mm/shmem: unconditionally setpte dirty in mfill_atomic_install_pte&#34;), we can use UFFDIO_CONTINUE to mapa shmem page R/O while marking the pte dirty.  This can be used byunprivileged user space to modify tmpfs/shmem file content even if theuser does not have write permissions to the file, and to bypass memfdwrite sealing -- Dirty COW restricted to tmpfs/shmem (CVE-2022-2590).To fix such security issues for good, the insight is that we really onlyneed that fancy retry logic (FOLL_COW) for COW mappings that are notwritable (!VM_WRITE).  And in a COW mapping, we really only broke COW ifwe have an exclusive anonymous page mapped.  If we have something elsemapped, or the mapped anonymous page might be shared (!PageAnonExclusive),we have to trigger a write fault to break COW.  If we don&#39;t find anexclusive anonymous page when we retry, we have to trigger COW breakingonce again because something intervened.Let&#39;s move away from this mandatory-retry + dirty handling and rely on ourPageAnonExclusive() flag for making a similar decision, to use the sameCOW logic as in other kernel parts here as well.  In case we stumble overa PTE in a COW mapping that does not map an exclusive anonymous page, COWwas not properly broken and we have to trigger a fake write-fault to breakCOW.Just like we do in can_change_pte_writable() added via commit 64fe24a3e05e(&#34;mm/mprotect: try avoiding write faults for exclusive anonymous pageswhen changing protection&#34;) and commit 76aefad628aa (&#34;mm/mprotect: fixsoft-dirty check in can_change_pte_writable()&#34;), take care of softdirtyand uffd-wp manually.For example, a write() via /proc/self/mem to a uffd-wp-protected range hasto fail instead of silently granting write access and bypassing theuserspace fault handler.  Note that FOLL_FORCE is not only used for debugaccess, but also triggered by applications without debug intentions, forexample, when pinning pages via RDMA.This fixes CVE-2022-2590. Note that only x86_64 and aarch64 areaffected, because only those support CONFIG_HAVE_ARCH_USERFAULTFD_MINOR.Fortunately, FOLL_COW is no longer required to handle FOLL_FORCE. Solet&#39;s just get rid of it.Thanks to Nadav Amit for pointing out that the pte_dirty() check inFOLL_FORCE code is problematic and might be exploitable.Note 1: We don&#39;t check for the PTE being dirty because it doesn&#39;t matterfor making a &#34;was COWed&#34; decision anymore, and whoever modifies thepage has to set the page dirty either way.Note 2: Kernels before extended uffd-wp support and beforePageAnonExclusive (&lt; 5.19) can simply revert the problematiccommit instead and be safe regarding UFFDIO_CONTINUE. A backport tov5.19 requires minor adjustments due to lack ofvma_soft_dirty_enabled().The Linux kernel CVE team has assigned CVE-2022-50014 to this issue.
 openEuler评分：
  7.0
 Vector：CVSS：3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
 受影响版本排查(受影响/不受影响)：
  1.master(6.12.33):不受影响
2.openEuler-20.03-LTS-SP4(4.19.90):不受影响
3.openEuler-22.03-LTS-SP3(5.10.0):不受影响
4.openEuler-22.03-LTS-SP4(5.10.0):不受影响
5.openEuler-24.03-LTS:不受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:不受影响
8.openEuler-24.03-LTS-SP2:不受影响

修复是否涉及abi变化(是/否)：
  1.master(6.12.33):否
2.openEuler-20.03-LTS-SP4(4.19.90):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.openEuler-22.03-LTS-SP4(5.10.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否
8.openEuler-24.03-LTS-SP2:否

原因说明：
  1.master(6.12.33):不受影响-漏洞代码不能被攻击者触发
2.openEuler-24.03-LTS:不受影响-漏洞代码不能被攻击者触发
3.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
4.openEuler-24.03-LTS-SP1:不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS-SP2:不受影响-漏洞代码不能被攻击者触发
6.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在
7.openEuler-22.03-LTS-SP3(5.10.0):不受影响-漏洞代码不存在
8.openEuler-22.03-LTS-SP4(5.10.0):不受影响-漏洞代码不存在

src-openEuler/kernel
关闭

内容风险标识

评论 (5)

src-openEuler/kernel关闭 .gitee-modal { width: 500px !important; }

内容风险标识

CVE-2022-50014

评论 (5)

搜索帮助

src-openEuler/kernel
关闭