From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Kuehling, Felix" <felix.kuehling@amd.com>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Willy Tarreau <w@1wt.eu>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Chris Wilson <chris@chris-wilson.co.uk>,
Matthew Auld <matthew.auld@intel.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Rik van Riel <riel@redhat.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linuxppc-dev@lists.ozlabs.org, stable@vger.kernel.org,
"Christian König" <christian.koenig@amd.com>,
"Chris Mason" <mason@kernel.org>
Subject: Re: [PATCH 5/5] mm: check permissions and bounds for vm_ops->access
Date: Fri, 13 Nov 2026 22:37:14 +0100 [thread overview]
Message-ID: <b290d347-1cd3-4ff1-b303-3cc074667689@kernel.org> (raw)
In-Reply-To: <4b9042de-973a-4036-a6a0-2294c65a1ee1@amd.com>
On 11/13/26 21:25, Kuehling, Felix wrote:
>
> On 2026-11-12 17:09, David Hildenbrand (Arm) wrote:
>> GUP rejects VM_IO and VM_PFNMAP mappings early. __access_remote_vm() then
>> falls back to vm_ops->access without checking VMA permissions and without
>> limiting the request to the VMA size.
>>
>> Consequently, /proc/<pid>/mem can bypass protections even without
>> FOLL_FORCE, or cross into another mapping without checking its
>> permissions.
>>
>> Check VMA permissions before calling ->access and limit each request to
>> the current VMA. Implement similar access permission checks as GUP,
>> however:
>> (1) Reject writes to CoW mappings because the callbacks access backing
>> memory directly and cannot handle CoW.
>> (2) Allow forced writes to non-CoW mappings with VM_MAYWRITE.
>>
>> This intentionally breaks forced writes through legacy amdgpu PROT_NONE,
>> MAP_PRIVATE debugger mappings. The workaround in commit fa5239f2af98
>> ("drm/amdgpu: workaround failed COW checks for Thunk VMAs") cleared
>> VM_MAYWRITE to avoid CoW, but debugger writes still succeeded by
>> exploiting the missing access-permission checks fixed here. Reads remain
>> supported. Userspace must use MAP_SHARED instead; ROCm 5.5.0, released
>> in May 2023, already does so.
>
> Thank you for considering this use case and checking the ROCm history. The patch is
>
> Acked-by: Felix Kuehling <felix.kuehling@amd.com>
Thanks a lot for the confirmation, appreciated!
--
Cheers,
David
next prev parent reply other threads:[~2026-11-13 21:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 22:08 [PATCH 0/5] mm,drm/i915,powerpc/spufs: vm_ops->access related fixes David Hildenbrand (Arm)
2026-11-12 22:08 ` [PATCH 1/5] mm: do not call vm_ops->access with FOLL_ANON David Hildenbrand (Arm)
2026-11-14 18:56 ` Lorenzo Stoakes (ARM)
2026-11-12 22:08 ` [PATCH 2/5] drm/i915: consider vm_pgoff in vm_access() David Hildenbrand (Arm)
2026-11-14 18:58 ` Lorenzo Stoakes (ARM)
2026-11-12 22:08 ` [PATCH 3/5] drm/i915/selftests: request read access for mmap access tests David Hildenbrand (Arm)
2026-11-14 18:58 ` Lorenzo Stoakes (ARM)
2026-11-12 22:09 ` [PATCH 4/5] powerpc/spufs: consider vm_pgoff in spufs_mem_mmap_access() David Hildenbrand (Arm)
2026-11-14 18:59 ` Lorenzo Stoakes (ARM)
2026-11-12 22:09 ` [PATCH 5/5] mm: check permissions and bounds for vm_ops->access David Hildenbrand (Arm)
2026-11-13 20:25 ` Kuehling, Felix
2026-11-13 21:37 ` David Hildenbrand (Arm) [this message]
2026-11-14 19:08 ` Lorenzo Stoakes (ARM)
2026-11-13 1:50 ` ✓ i915.CI.BAT: success for mm,drm/i915,powerpc/spufs: vm_ops->access related fixes Patchwork
2026-11-14 3:28 ` ✗ i915.CI.Full: failure " Patchwork
2026-11-14 16:17 ` [PATCH 0/5] " David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b290d347-1cd3-4ff1-b303-3cc074667689@kernel.org \
--to=david@kernel.org \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=chleroy@kernel.org \
--cc=chris@chris-wilson.co.uk \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ljs@kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mason@kernel.org \
--cc=matthew.auld@intel.com \
--cc=mhocko@suse.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=riel@redhat.com \
--cc=ritesh.list@gmail.com \
--cc=rodrigo.vivi@intel.com \
--cc=rppt@kernel.org \
--cc=simona@ffwll.ch \
--cc=sshegde@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=tursulin@ursulin.net \
--cc=vbabka@kernel.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.