From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754274AbbDGNKf (ORCPT ); Tue, 7 Apr 2015 09:10:35 -0400 Received: from ip4-83-240-67-251.cust.nbox.cz ([83.240.67.251]:54490 "EHLO ip4-83-240-18-248.cust.nbox.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754119AbbDGMwI (ORCPT ); Tue, 7 Apr 2015 08:52:08 -0400 From: Jiri Slaby To: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Dave Hansen , Manfred Spraul , Andrew Morton , Linus Torvalds , Jiri Slaby Subject: [PATCH 3.12 077/155] ipc/shm.c: fix overly aggressive shmdt() when calls span multiple segments Date: Tue, 7 Apr 2015 14:50:46 +0200 Message-Id: <2e229b9bb75f98ec2fe7d5b0ff998d293c5ad410.1428411004.git.jslaby@suse.cz> X-Mailer: git-send-email 2.3.4 In-Reply-To: <9a548862b8a26cbccc14f2c6c9c3688813d8d14b.1428411003.git.jslaby@suse.cz> References: <9a548862b8a26cbccc14f2c6c9c3688813d8d14b.1428411003.git.jslaby@suse.cz> In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Hansen 3.12-stable review patch. If anyone has any objections, please let me know. =============== commit d3c97900b427b8d5a476fdfe484267f09df418d6 upstream. This is a highly-contrived scenario. But, a single shmdt() call can be induced in to unmapping memory from mulitple shm segments. Example code is here: http://www.sr71.net/~dave/intel/shmfun.c The fix is pretty simple: Record the 'struct file' for the first VMA we encounter and then stick to it. Decline to unmap anything not from the same file and thus the same segment. I found this by inspection and the odds of anyone hitting this in practice are pretty darn small. Lightly tested, but it's a pretty small patch. Signed-off-by: Dave Hansen Cc: Manfred Spraul Reviewed-by: Davidlohr Bueso Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby --- ipc/shm.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/ipc/shm.c b/ipc/shm.c index 7a51443a51d6..b039a85e2b8d 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -1227,6 +1227,7 @@ SYSCALL_DEFINE1(shmdt, char __user *, shmaddr) int retval = -EINVAL; #ifdef CONFIG_MMU loff_t size = 0; + struct file *file; struct vm_area_struct *next; #endif @@ -1243,7 +1244,8 @@ SYSCALL_DEFINE1(shmdt, char __user *, shmaddr) * started at address shmaddr. It records it's size and then unmaps * it. * - Then it unmaps all shm vmas that started at shmaddr and that - * are within the initially determined size. + * are within the initially determined size and that are from the + * same shm segment from which we determined the size. * Errors from do_munmap are ignored: the function only fails if * it's called with invalid parameters or if it's called to unmap * a part of a vma. Both calls in this function are for full vmas, @@ -1269,8 +1271,14 @@ SYSCALL_DEFINE1(shmdt, char __user *, shmaddr) if ((vma->vm_ops == &shm_vm_ops) && (vma->vm_start - addr)/PAGE_SIZE == vma->vm_pgoff) { - - size = file_inode(vma->vm_file)->i_size; + /* + * Record the file of the shm segment being + * unmapped. With mremap(), someone could place + * page from another segment but with equal offsets + * in the range we are unmapping. + */ + file = vma->vm_file; + size = file_inode(file)->i_size; do_munmap(mm, vma->vm_start, vma->vm_end - vma->vm_start); /* * We discovered the size of the shm segment, so @@ -1296,8 +1304,8 @@ SYSCALL_DEFINE1(shmdt, char __user *, shmaddr) /* finding a matching vma now does not alter retval */ if ((vma->vm_ops == &shm_vm_ops) && - (vma->vm_start - addr)/PAGE_SIZE == vma->vm_pgoff) - + ((vma->vm_start - addr)/PAGE_SIZE == vma->vm_pgoff) && + (vma->vm_file == file)) do_munmap(mm, vma->vm_start, vma->vm_end - vma->vm_start); vma = next; } -- 2.3.4