| From bippy-7c5fe7eed585 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-2025-21939: drm/xe/hmm: Don't dereference struct page pointers without notifier lock |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| drm/xe/hmm: Don't dereference struct page pointers without notifier lock |
| |
| The pnfs that we obtain from hmm_range_fault() point to pages that |
| we don't have a reference on, and the guarantee that they are still |
| in the cpu page-tables is that the notifier lock must be held and the |
| notifier seqno is still valid. |
| |
| So while building the sg table and marking the pages accesses / dirty |
| we need to hold this lock with a validated seqno. |
| |
| However, the lock is reclaim tainted which makes |
| sg_alloc_table_from_pages_segment() unusable, since it internally |
| allocates memory. |
| |
| Instead build the sg-table manually. For the non-iommu case |
| this might lead to fewer coalesces, but if that's a problem it can |
| be fixed up later in the resource cursor code. For the iommu case, |
| the whole sg-table may still be coalesced to a single contigous |
| device va region. |
| |
| This avoids marking pages that we don't own dirty and accessed, and |
| it also avoid dereferencing struct pages that we don't own. |
| |
| v2: |
| - Use assert to check whether hmm pfns are valid (Matthew Auld) |
| - Take into account that large pages may cross range boundaries |
| (Matthew Auld) |
| |
| v3: |
| - Don't unnecessarily check for a non-freed sg-table. (Matthew Auld) |
| - Add a missing up_read() in an error path. (Matthew Auld) |
| |
| (cherry picked from commit ea3e66d280ce2576664a862693d1da8fd324c317) |
| |
| The Linux kernel CVE team has assigned CVE-2025-21939 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.10 with commit 81e058a3e7fd8593d076b4f26f7b8bb49f1d61e3 and fixed in 6.12.19 with commit 2a24c98f0e4cc994334598d4f3a851972064809d |
| Issue introduced in 6.10 with commit 81e058a3e7fd8593d076b4f26f7b8bb49f1d61e3 and fixed in 6.13.7 with commit f9326f529da7298a95643c3267f1c0fdb0db55eb |
| Issue introduced in 6.10 with commit 81e058a3e7fd8593d076b4f26f7b8bb49f1d61e3 and fixed in 6.14 with commit 0a98219bcc961edd3388960576e4353e123b4a51 |
| |
| 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-2025-21939 |
| 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: |
| drivers/gpu/drm/xe/xe_hmm.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/2a24c98f0e4cc994334598d4f3a851972064809d |
| https://git.kernel.org/stable/c/f9326f529da7298a95643c3267f1c0fdb0db55eb |
| https://git.kernel.org/stable/c/0a98219bcc961edd3388960576e4353e123b4a51 |
