From patchwork Wed Mar 4 14:02:49 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Szyprowski X-Patchwork-Id: 5940231 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 28D129FB2D for ; Wed, 4 Mar 2015 20:50:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4467720303 for ; Wed, 4 Mar 2015 20:50:48 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id CE2372035B for ; Wed, 4 Mar 2015 20:50:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2FBDE6E2EE; Wed, 4 Mar 2015 12:50:38 -0800 (PST) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mailout4.w1.samsung.com (mailout4.w1.samsung.com [210.118.77.14]) by gabe.freedesktop.org (Postfix) with ESMTP id 884EF6E28C for ; Wed, 4 Mar 2015 06:03:06 -0800 (PST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NKO00MIPXVP7WA0@mailout4.w1.samsung.com> for dri-devel@lists.freedesktop.org; Wed, 04 Mar 2015 14:07:01 +0000 (GMT) X-AuditID: cbfec7f5-b7fc86d0000066b7-cc-54f71002a537 Received: from eusync1.samsung.com ( [203.254.199.211]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 8F.B8.26295.20017F45; Wed, 04 Mar 2015 14:00:34 +0000 (GMT) Received: from amdc1339.digital.local ([106.116.147.30]) by eusync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0NKO00HFQXOZU1C0@eusync1.samsung.com>; Wed, 04 Mar 2015 14:03:03 +0000 (GMT) From: Marek Szyprowski To: linux-samsung-soc@vger.kernel.org Subject: [PATCH] drm/exynos/ipp: Validate buffer enqueue requests Date: Wed, 04 Mar 2015 15:02:49 +0100 Message-id: <1425477769-5430-1-git-send-email-m.szyprowski@samsung.com> X-Mailer: git-send-email 1.9.2 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEJMWRmVeSWpSXmKPExsVy+t/xy7pMAt9DDPbvZrW4te4cq8W0Gf3s Fle+vmezmHR/AovFi3sXWSxmnN/HZLH2yF12B3aP+93HmTz6tqxi9Pi8SS6AOYrLJiU1J7Ms tUjfLoErY9V6g4K9ohU7L75jbWA8K9jFyMkhIWAicfXpIkYIW0ziwr31bF2MXBxCAksZJT5P OQnl9DFJdE8/xgZSxSZgKNH1tgvMFhFQlfjctoAdpIhZ4AGjRMfFz0AOB4ewgKPEpMvFIDUs QDXHdu1hBAnzCrhLHO1ThFgmJ/H/5QqmCYzcCxgZVjGKppYmFxQnpeca6RUn5haX5qXrJefn bmKEhMPXHYxLj1kdYhTgYFTi4S1I+hYixJpYVlyZe4hRgoNZSYT3Odv3ECHelMTKqtSi/Pii 0pzU4kOMTBycUg2Mscz/9s6rd900bcFsv4/dryPcPPfr7S62yLMQWuhrK7c7qFrnTZN2X8ii D6/9BbcbX5I6L9N4zLBR5HPrsx8G5RFb/omvX785W9bz2zTzEuH9mev/5D6u6U9iz1nptUeP 7X3urLSLJedZ7OWqD8r7ap4KzDdx+Jj55MD094cmrz0n92G/0dsyJZbijERDLeai4kQAsWWT lOUBAAA= X-Mailman-Approved-At: Wed, 04 Mar 2015 12:50:37 -0800 Cc: dri-devel@lists.freedesktop.org, Andrzej Hajda , Beata Michalska , Marek Szyprowski X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Beata Michalska As for now there is no validation of incoming buffer enqueue request as far as the gem buffers are being concerned. This might lead to some undesired cases when the driver tries to operate on invalid buffers (wiht no valid gem object handle i.e.). Add some basic checks to rule out those potential issues. Signed-off-by: Beata Michalska [mszyprow: rebased onto v4.0-rc1 and adapted to recent ipp changes] Signed-off-by: Marek Szyprowski --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 44 +++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index 12ae9c4..ac35625 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -476,6 +476,45 @@ err_clear: return ret; } +static int ipp_validate_mem_node(struct drm_device *drm_dev, + struct drm_exynos_ipp_mem_node *m_node, + struct drm_exynos_ipp_cmd_node *c_node) +{ + struct drm_exynos_ipp_config *ipp_cfg; + unsigned int num_plane; + unsigned long min_size, size; + unsigned int bpp; + int i; + + /* The property id should already be varified */ + ipp_cfg = &c_node->property.config[m_node->prop_id]; + num_plane = drm_format_num_planes(ipp_cfg->fmt); + + /** + * This is a rather simplified validation of a memory node. + * It basically verifies provided gem object handles + * and the buffer sizes with respect to current configuration. + * This is not the best that can be done + * but it seems more than enough + */ + for (i = 0; i < num_plane; ++i) { + if (!m_node->buf_info.handles[i]) { + DRM_ERROR("invalid handle for plane %d\n", i); + return -EINVAL; + } + bpp = drm_format_plane_cpp(ipp_cfg->fmt, i); + min_size = (ipp_cfg->sz.hsize * ipp_cfg->sz.vsize * bpp) >> 3; + size = exynos_drm_gem_get_size(drm_dev, + m_node->buf_info.handles[i], + c_node->filp); + if (min_size > size) { + DRM_ERROR("invalid size for plane %d\n", i); + return -EINVAL; + } + } + return 0; +} + static int ipp_put_mem_node(struct drm_device *drm_dev, struct drm_exynos_ipp_cmd_node *c_node, struct drm_exynos_ipp_mem_node *m_node) @@ -552,6 +591,11 @@ static struct drm_exynos_ipp_mem_node } mutex_lock(&c_node->mem_lock); + if (ipp_validate_mem_node(drm_dev, m_node, c_node)) { + ipp_put_mem_node(drm_dev, c_node, m_node); + mutex_unlock(&c_node->mem_lock); + return ERR_PTR(-EFAULT); + } list_add_tail(&m_node->list, &c_node->mem_list[qbuf->ops_id]); mutex_unlock(&c_node->mem_lock);