linux-kernel - Re: [PATCH] dma-remap: fix dma_common_find

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1d552f40-74b3-4c6d-874d-508ecb0e75d2@arm.com>
Date: Mon, 15 Dec 2025 11:31:32 +0000
From: Robin Murphy <robin.murphy@....com>
To: Marek Szyprowski <m.szyprowski@...sung.com>,
 Christoph Hellwig <hch@...radead.org>,
 Andrei-Edward Popa <andrei.popa105@...oo.com>
Cc: iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dma-remap: fix dma_common_find_pages() page lookup for
 offsets

On 2025-12-15 8:13 am, Marek Szyprowski wrote:
> On 15.12.2025 06:57, Christoph Hellwig wrote:
>> On Fri, Dec 12, 2025 at 10:09:14PM +0200, Andrei-Edward Popa wrote:
>>> dma_common_find_pages() previously assumed that the CPU virtual address
>>> always pointed to the start of a DMA-coherent allocation. This fails when
>>> memory is allocated via dma_alloc_attrs() without DMA_ATTR_FORCE_CONTIGUOUS
>>> and then subdivided into smaller blocks using a gen_pool, relevant only
>>> when an IOMMU is enabled.
>>>
>>> In such cases, userspace may request a mapping via dma_mmap_attrs()
>>> for a CPU address that is offset inside the original allocation. The
>>> previous code could return the wrong struct page pointer.
>> No, you can't mmap part of a dma coherent allocation.  What caller is
>> trying to do this?  It needs to be fixed instead.
> 
> I wonder if this was ever explicitly stated.

Seems it never made it into the text documentation, but it is stated in 
the kerneldoc.

> dma_mmap_coherent() was initially added for mmapeing a
> dma_alloc_coherent()-allocated buffer for fbdev and alsa, and at least
> the first one allowed to mmap the buffer partially or starting at
> non-zero offset. I doubt that this feature was useful for anything, but
> I'm quite sure this was at least allowed and there were some comments in
> the code about that.

Mapping part of a buffer in general is fine, provided the fd advertised 
to userspace represents the entire buffer - then the offset/size of the 
VMA determine how much of it actually gets mapped. What you can't do is 
advertise parts of a buffer *as separate fds* and then expect to pass 
mmap calls on those straight through, without adjusting them to be 
relative to the whole buffer.

We don't provide such a generic helper for mmap'ing from a generic 
dma_pool, largely because the main point of those is for drivers that 
want to allocate lots of buffers smaller than PAGE_SIZE, such that 
trying to mmap them to userspace would most likely be a giant security 
hole anyway.

Thanks,
Robin.