Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp455163imu; Wed, 2 Jan 2019 09:46:53 -0800 (PST) X-Google-Smtp-Source: AFSGD/XEg6XaxJ4hJ/UJ5QM5feqGSSQV59h+ackQFQ8qWC6wi4k1FzM1nyui7y/FOIiHAE+8LZ85 X-Received: by 2002:a62:938f:: with SMTP id r15mr44985408pfk.27.1546451212961; Wed, 02 Jan 2019 09:46:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546451212; cv=none; d=google.com; s=arc-20160816; b=NHWgFeAzUR9lSPz/JT/gJOjM/yFUK7teWjnLN1TKMXEZA2x6x5JtSGEppLsUVl9aub 6jyyedY+RCyPPDIwNshYSu0gssO+0bw5Al3jNK7ZoFDgh8QeVQtSa0piOzVxMAfN4pLg Y+CrJtC/EcbVeIX9l9c31vRKDkzgMMWlc4z/lR+NEjho6CLrgGjQhebd77wBHFVr+mGJ VaBcNLD/s5AzhPnafVVko4B0aSXojqOor5W15lPvT1fPr2pw0Zs095xKNDOM34JSSx/x NPv4HI/mgAFbkIQLteacgfQskEMbgAHNeZTDTPgKJyHWOuu1L6z7/k8yU5cLxwHgTwnR K9UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=IJHL/z8fAJRE9Iyf8aCknufDky6L83+nNxnmSNmWUL0=; b=nFU4an0A2r43QQsu0hmC409wQ2mySD1x8OremlAiX9eQlGeisIUi56q3kKMLDHny7F nta/TzD6Eabp8dhWT2bU/eRGR7Zk3NiicIRbjKtabpvtffmYBziilQYr+7iaVWyhSQuW PmVk58FkyBYWD8pstvhXccxpWMncg9lEMhnt2I4p1dGhXrs1AzZ3nveaZjoOknyqxhN+ 0/Jb6nNmLECiF9UuSKWDqPcIV6g/9Ek5cdXf1mxQ6HLuyi3uKwNGPR4sdjQAvNpbsgVt QmSsKLVZq+JkNFrJ7j3hbUW0tA0P2rRj6GQXtiza4UwQ+0RDh81ps/i40JnQEX1OqP5f zdRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=umkUwBVI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y126si14053346pgb.165.2019.01.02.09.46.18; Wed, 02 Jan 2019 09:46:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=umkUwBVI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730206AbfABPsr (ORCPT + 99 others); Wed, 2 Jan 2019 10:48:47 -0500 Received: from mail-lj1-f193.google.com ([209.85.208.193]:43286 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727038AbfABPsr (ORCPT ); Wed, 2 Jan 2019 10:48:47 -0500 Received: by mail-lj1-f193.google.com with SMTP id q2-v6so27324796lji.10; Wed, 02 Jan 2019 07:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IJHL/z8fAJRE9Iyf8aCknufDky6L83+nNxnmSNmWUL0=; b=umkUwBVIN/yYk5VwfS+MFZuorx2FzrD4Ze8CM4JeoYDHkxfZVPYebJlrJjnTp31bzJ AHyYuoq0NXSLLnJ4Re5PjaIZin8goaV7udqBZlTV1dFLZjHnDPcocwxp89M9MBSmKiU4 4EFxApWVdmqBEDoxVHxbdHxO+6zwE6Az5P4Rq6Tl+48rQPsUn/xFZVOSSCbcbbbO1XNi RZ69pUN3T8cFQelu1sY+YuZokaNt/BIufx9VkrqbfrDKtJ3fjqWHOY8NJORHNkjryw/4 swnyr/5PaEMVABHNSCWzKb+7OQJq0uN7GaBYc9b41jzAsNZ2exlajrGZheN08nXSq0SX M3xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IJHL/z8fAJRE9Iyf8aCknufDky6L83+nNxnmSNmWUL0=; b=LrDA593DZ+2wRmC9jmyXTGa2DukxpLif1IBpuc77GUjxF5SSeDSeTvDf10hu6xrndu /YnKIk1MLcbZl7RgQyf7v4aNUrV7k1F7ios0nSZXXY4pNmjQ89TdhMfL4HLcIaiuYaSo W0n0XMF4eD7e1be8ttHpGf70zh6MQNDVU4dljDwvoikr/m5feKE3haUt9XvPG7i/Lu6M mmAWXTeiFSYeY3QzE6dWFXYwY00XHWkofOtT8mk2KGb+vwc4jXytx0+KGrS1On+8CaQz pT11u2wEKvhenUEK5af8Hc0JEEkzs9HX3BxBQnwNvRSObFU+w21mrVSPoWtTR1ChPKI7 1ySw== X-Gm-Message-State: AJcUukfhjcnxcaFoE+Yw6BN4vW0pWIe4sVWLEHLZg5JK6yh6OreIRLjA 7ivBx7X55bjOhwuGgAN6/FhQ03D0gk5ITZaDFEs= X-Received: by 2002:a2e:9c52:: with SMTP id t18-v6mr20634319ljj.149.1546444124257; Wed, 02 Jan 2019 07:48:44 -0800 (PST) MIME-Version: 1.0 References: <20181224132658.GA22166@jordon-HP-15-Notebook-PC> <20190102111553.GG26090@n2100.armlinux.org.uk> In-Reply-To: <20190102111553.GG26090@n2100.armlinux.org.uk> From: Souptick Joarder Date: Wed, 2 Jan 2019 21:22:34 +0530 Message-ID: Subject: Re: [PATCH v5 7/9] videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range To: Russell King - ARM Linux Cc: Andrew Morton , Matthew Wilcox , Michal Hocko , pawel@osciak.com, Marek Szyprowski , Kyungmin Park , mchehab@kernel.org, robin.murphy@arm.com, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Linux-MM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 2, 2019 at 4:46 PM Russell King - ARM Linux wrote: > > On Wed, Jan 02, 2019 at 04:23:15PM +0530, Souptick Joarder wrote: > > On Mon, Dec 24, 2018 at 6:53 PM Souptick Joarder wrote: > > > > > > Convert to use vm_insert_range to map range of kernel memory > > > to user vma. > > > > > > Signed-off-by: Souptick Joarder > > > Reviewed-by: Matthew Wilcox > > > Acked-by: Marek Szyprowski > > > Acked-by: Mauro Carvalho Chehab > > > --- > > > drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 +++++++---------------- > > > 1 file changed, 7 insertions(+), 16 deletions(-) > > > > > > diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c > > > index 015e737..898adef 100644 > > > --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c > > > +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c > > > @@ -328,28 +328,19 @@ static unsigned int vb2_dma_sg_num_users(void *buf_priv) > > > static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma) > > > { > > > struct vb2_dma_sg_buf *buf = buf_priv; > > > - unsigned long uaddr = vma->vm_start; > > > - unsigned long usize = vma->vm_end - vma->vm_start; > > > - int i = 0; > > > + unsigned long page_count = vma_pages(vma); > > > + int err; > > > > > > if (!buf) { > > > printk(KERN_ERR "No memory to map\n"); > > > return -EINVAL; > > > } > > > > > > - do { > > > - int ret; > > > - > > > - ret = vm_insert_page(vma, uaddr, buf->pages[i++]); > > > - if (ret) { > > > - printk(KERN_ERR "Remapping memory, error: %d\n", ret); > > > - return ret; > > > - } > > > - > > > - uaddr += PAGE_SIZE; > > > - usize -= PAGE_SIZE; > > > - } while (usize > 0); > > > - > > > + err = vm_insert_range(vma, vma->vm_start, buf->pages, page_count); > > > + if (err) { > > > + printk(KERN_ERR "Remapping memory, error: %d\n", err); > > > + return err; > > > + } > > > > > > > Looking into the original code - > > drivers/media/common/videobuf2/videobuf2-dma-sg.c > > > > Inside vb2_dma_sg_alloc(), > > ... > > buf->num_pages = size >> PAGE_SHIFT; > > buf->dma_sgt = &buf->sg_table; > > > > buf->pages = kvmalloc_array(buf->num_pages, sizeof(struct page *), > > GFP_KERNEL | __GFP_ZERO); > > ... > > > > buf->pages has index upto *buf->num_pages*. > > > > now inside vb2_dma_sg_mmap(), > > > > unsigned long usize = vma->vm_end - vma->vm_start; > > int i = 0; > > ... > > do { > > int ret; > > > > ret = vm_insert_page(vma, uaddr, buf->pages[i++]); > > if (ret) { > > printk(KERN_ERR "Remapping memory, error: > > %d\n", ret); > > return ret; > > } > > > > uaddr += PAGE_SIZE; > > usize -= PAGE_SIZE; > > } while (usize > 0); > > ... > > is it possible for any value of *i > (buf->num_pages)*, > > buf->pages[i] is going to overrun the page boundary ? > > Yes it is, and you've found an array-overrun condition that is > triggerable from userspace - potentially non-root userspace too. > Depending on what it can cause to be mapped without oopsing the > kernel, it could be very serious. At best, it'll oops the kernel. > At worst, it could expose pages of memory that userspace should > not have access to. > > This is why I've been saying that we need a helper that takes the > _object_ and the user request, and does all the checking internally, > so these kinds of checks do not get overlooked. ok, while replacing this code with the suggested vm_insert_range_buggy(), we could fixed this issue. > > A good API is one that helpers authors avoid bugs. > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up