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)
Metrics
Affected Vendors & Products
| Source | ID | Title | 
|---|---|---|
|  EUVD | EUVD-2025-9382 | 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) | 
|  Ubuntu USN | USN-7605-1 | Linux kernel vulnerabilities | 
|  Ubuntu USN | USN-7605-2 | Linux kernel (Low Latency) vulnerabilities | 
|  Ubuntu USN | USN-7606-1 | Linux kernel (OEM) vulnerabilities | 
|  Ubuntu USN | USN-7628-1 | Linux kernel (Azure) vulnerabilities | 
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Thu, 30 Oct 2025 19:45:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| First Time appeared | Linux Linux linux Kernel | |
| Weaknesses | CWE-476 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:* | |
| Vendors & Products | Linux Linux linux Kernel | |
| Metrics | cvssV3_1 
 | cvssV3_1 
 | 
Fri, 23 May 2025 06:45:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| Weaknesses | CWE-667 | |
| Metrics | cvssV3_1 
 
 | cvssV3_1 
 
 | 
Wed, 02 Apr 2025 14:00:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| References |  | |
| Metrics | threat_severity 
 | cvssV3_1 
 
 | 
Tue, 01 Apr 2025 16:00:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| 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) | |
| Title | drm/xe/hmm: Don't dereference struct page pointers without notifier lock | |
| References |  | 
 MITRE
                        MITRE
                    Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-05-04T07:25:05.653Z
Reserved: 2024-12-29T08:45:45.789Z
Link: CVE-2025-21939
 Vulnrichment
                        Vulnrichment
                    No data.
 NVD
                        NVD
                    Status : Analyzed
Published: 2025-04-01T16:15:24.773
Modified: 2025-10-30T19:44:02.160
Link: CVE-2025-21939
 Redhat
                        Redhat
                     OpenCVE Enrichment
                        OpenCVE Enrichment
                    No data.