| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2022-48797: mm: don't try to NUMA-migrate COW pages that have other uses |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| mm: don't try to NUMA-migrate COW pages that have other uses |
| |
| Oded Gabbay reports that enabling NUMA balancing causes corruption with |
| his Gaudi accelerator test load: |
| |
| "All the details are in the bug, but the bottom line is that somehow, |
| this patch causes corruption when the numa balancing feature is |
| enabled AND we don't use process affinity AND we use GUP to pin pages |
| so our accelerator can DMA to/from system memory. |
| |
| Either disabling numa balancing, using process affinity to bind to |
| specific numa-node or reverting this patch causes the bug to |
| disappear" |
| |
| and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page() |
| simplification"). |
| |
| Now, the NUMA balancing shouldn't actually be changing the writability |
| of a page, and as such shouldn't matter for COW. But it appears it |
| does. Suspicious. |
| |
| However, regardless of that, the condition for enabling NUMA faults in |
| change_pte_range() is nonsensical. It uses "page_mapcount(page)" to |
| decide if a COW page should be NUMA-protected or not, and that makes |
| absolutely no sense. |
| |
| The number of mappings a page has is irrelevant: not only does GUP get a |
| reference to a page as in Oded's case, but the other mappings migth be |
| paged out and the only reference to them would be in the page count. |
| |
| Since we should never try to NUMA-balance a page that we can't move |
| anyway due to other references, just fix the code to use 'page_count()'. |
| Oded confirms that that fixes his issue. |
| |
| Now, this does imply that something in NUMA balancing ends up changing |
| page protections (other than the obvious one of making the page |
| inaccessible to get the NUMA faulting information). Otherwise the COW |
| simplification wouldn't matter - since doing the GUP on the page would |
| make sure it's writable. |
| |
| The cause of that permission change would be good to figure out too, |
| since it clearly results in spurious COW events - but fixing the |
| nonsensical test that just happened to work before is obviously the |
| CorrectThing(tm) to do regardless. |
| |
| The Linux kernel CVE team has assigned CVE-2022-48797 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 5.9 with commit 09854ba94c6aad7886996bfbee2530b3d8a7f4f4 and fixed in 5.10.102 with commit 254090925e16abd914c87b4ad1b489440d89c4c3 |
| Issue introduced in 5.9 with commit 09854ba94c6aad7886996bfbee2530b3d8a7f4f4 and fixed in 5.15.25 with commit b3dc4b9d3ca68b370c4aeab5355007eedf948849 |
| Issue introduced in 5.9 with commit 09854ba94c6aad7886996bfbee2530b3d8a7f4f4 and fixed in 5.16.11 with commit d187eeb02d18446e5e54ed6bcbf8b47e6551daea |
| Issue introduced in 5.9 with commit 09854ba94c6aad7886996bfbee2530b3d8a7f4f4 and fixed in 5.17 with commit 80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6 |
| |
| 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-2022-48797 |
| 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: |
| mm/mprotect.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/254090925e16abd914c87b4ad1b489440d89c4c3 |
| https://git.kernel.org/stable/c/b3dc4b9d3ca68b370c4aeab5355007eedf948849 |
| https://git.kernel.org/stable/c/d187eeb02d18446e5e54ed6bcbf8b47e6551daea |
| https://git.kernel.org/stable/c/80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6 |