If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the comedi_mmap() error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case").
Cc: stable@vger.kernel.org Fixes: ed9eccbe8970 ("Staging: add comedi core") Signed-off-by: Jann Horn jannh@google.com --- Note: compile-tested only; I don't actually have comedi hardware, and I don't know anything about comedi. --- drivers/comedi/comedi_fops.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/comedi/comedi_fops.c b/drivers/comedi/comedi_fops.c index 1b481731df96..0e573df8646f 100644 --- a/drivers/comedi/comedi_fops.c +++ b/drivers/comedi/comedi_fops.c @@ -2414,6 +2414,15 @@ static int comedi_mmap(struct file *file, struct vm_area_struct *vma) vma->vm_private_data = bm;
vma->vm_ops->open(vma); + } else { + /* + * Leaving behind a partial mapping of a buffer we're about to + * drop is unsafe, see remap_pfn_range_notrack(). + * We need to zap the range here ourselves instead of relying + * on the automatic zapping in remap_pfn_range() because we call + * remap_pfn_range() in a loop. + */ + zap_page_range_single(vma, vma->vm_start, size, NULL); }
done:
--- base-commit: 6485cf5ea253d40d507cd71253c9568c5470cd27 change-id: 20241014-comedi-tlb-400246505961
On 14/10/2024 21:50, Jann Horn wrote:
If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the comedi_mmap() error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case").
Cc: stable@vger.kernel.org
Your patched version won't compile before 6.1 so you may want to indicate that in the Cc line.
Fixes: ed9eccbe8970 ("Staging: add comedi core") Signed-off-by: Jann Horn jannh@google.com
Note: compile-tested only; I don't actually have comedi hardware, and I don't know anything about comedi.
drivers/comedi/comedi_fops.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/comedi/comedi_fops.c b/drivers/comedi/comedi_fops.c index 1b481731df96..0e573df8646f 100644 --- a/drivers/comedi/comedi_fops.c +++ b/drivers/comedi/comedi_fops.c @@ -2414,6 +2414,15 @@ static int comedi_mmap(struct file *file, struct vm_area_struct *vma) vma->vm_private_data = bm; vma->vm_ops->open(vma);
- } else {
/** Leaving behind a partial mapping of a buffer we're about to* drop is unsafe, see remap_pfn_range_notrack().* We need to zap the range here ourselves instead of relying* on the automatic zapping in remap_pfn_range() because we call* remap_pfn_range() in a loop.*/zap_page_range_single(vma, vma->vm_start, size, NULL);done:
base-commit: 6485cf5ea253d40d507cd71253c9568c5470cd27 change-id: 20241014-comedi-tlb-400246505961
I guess this doesn't need to be done for the path that calls dma_mmap_coherent() since that does not do any range splitting. Would it be better to move it into the branch that calls remap_pfn_range() in a loop?
Note that I have no commit access to pulled-from repositories. Greg-KH usually commits them on one of his repos, so could you Cc him too? Thanks.
On Tue, Oct 15, 2024 at 12:19 PM Ian Abbott abbotti@mev.co.uk wrote:
On 14/10/2024 21:50, Jann Horn wrote:
If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the comedi_mmap() error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case").
Cc: stable@vger.kernel.org
Your patched version won't compile before 6.1 so you may want to indicate that in the Cc line.
Ah, thanks for pointing that out - I can just use zap_vma_ptes() instead, which is available in older kernels, that way it will be more concise and the backport will be easier.
Fixes: ed9eccbe8970 ("Staging: add comedi core") Signed-off-by: Jann Horn jannh@google.com
Note: compile-tested only; I don't actually have comedi hardware, and I don't know anything about comedi.
drivers/comedi/comedi_fops.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/comedi/comedi_fops.c b/drivers/comedi/comedi_fops.c index 1b481731df96..0e573df8646f 100644 --- a/drivers/comedi/comedi_fops.c +++ b/drivers/comedi/comedi_fops.c @@ -2414,6 +2414,15 @@ static int comedi_mmap(struct file *file, struct vm_area_struct *vma) vma->vm_private_data = bm;
vma->vm_ops->open(vma);
} else {/** Leaving behind a partial mapping of a buffer we're about to* drop is unsafe, see remap_pfn_range_notrack().* We need to zap the range here ourselves instead of relying* on the automatic zapping in remap_pfn_range() because we call* remap_pfn_range() in a loop.*/zap_page_range_single(vma, vma->vm_start, size, NULL); }done:
base-commit: 6485cf5ea253d40d507cd71253c9568c5470cd27 change-id: 20241014-comedi-tlb-400246505961
I guess this doesn't need to be done for the path that calls dma_mmap_coherent() since that does not do any range splitting. Would it be better to move it into the branch that calls remap_pfn_range() in a loop?
Sure, I'll move it up into the branch.
Note that I have no commit access to pulled-from repositories. Greg-KH usually commits them on one of his repos, so could you Cc him too? Thanks.
Ack, will do.
linux-stable-mirror@lists.linaro.org
-
Ian Abbott -
Jann Horn