Bug 2365283 (CVE-2025-37868) - CVE-2025-37868 kernel: drm/xe/userptr: fix notifier vs folio deadlock
Summary: CVE-2025-37868 kernel: drm/xe/userptr: fix notifier vs folio deadlock
Keywords:
Status: NEW
Alias: CVE-2025-37868
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-05-09 07:03 UTC by OSIDB Bzimport
Modified: 2025-05-09 08:18 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2025-05-09 07:03:15 UTC
In the Linux kernel, the following vulnerability has been resolved:

drm/xe/userptr: fix notifier vs folio deadlock

User is reporting what smells like notifier vs folio deadlock, where
migrate_pages_batch() on core kernel side is holding folio lock(s) and
then interacting with the mappings of it, however those mappings are
tied to some userptr, which means calling into the notifier callback and
grabbing the notifier lock. With perfect timing it looks possible that
the pages we pulled from the hmm fault can get sniped by
migrate_pages_batch() at the same time that we are holding the notifier
lock to mark the pages as accessed/dirty, but at this point we also want
to grab the folio locks(s) to mark them as dirty, but if they are
contended from notifier/migrate_pages_batch side then we deadlock since
folio lock won't be dropped until we drop the notifier lock.

Fortunately the mark_page_accessed/dirty is not really needed in the
first place it seems and should have already been done by hmm fault, so
just remove it.

(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)


Note You need to log in before you can comment on or make changes to this bug.