From patchwork Tue Jan 16 21:52:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 10168229 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A5680600CA for ; Tue, 16 Jan 2018 21:53:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9558623F88 for ; Tue, 16 Jan 2018 21:53:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 89A5825E13; Tue, 16 Jan 2018 21:53:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DD02823F88 for ; Tue, 16 Jan 2018 21:53:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751396AbeAPVxF (ORCPT ); Tue, 16 Jan 2018 16:53:05 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:55789 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbeAPVxE (ORCPT ); Tue, 16 Jan 2018 16:53:04 -0500 Received: from wuerfel.lan ([95.208.111.237]) by mrelayeu.kundenserver.de (mreue102 [212.227.15.145]) with ESMTPA (Nemesis) id 0MdLdb-1eJcw207Xf-00ISoj; Tue, 16 Jan 2018 22:52:45 +0100 From: Arnd Bergmann To: Sylwester Nawrocki , Mauro Carvalho Chehab Cc: Arnd Bergmann , Laurent Pinchart , Sakari Ailus , linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] [v4] media: s3c-camif: fix out-of-bounds array access Date: Tue, 16 Jan 2018 22:52:15 +0100 Message-Id: <20180116215242.784423-1-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 X-Provags-ID: V03:K0:WwOnsmf3aFRIiR3HV2L9hQ/LjltjRSgEECH/EXeX7SRCzuipH55 Sc0wNMEWEApzBZ7qV9YpZpAhOXNrlarIHya0k+tny40XBFvOyQabYwtrDIUiZBMZqplYgK7 ZIkPGpSHhQ98sMZaGs7m7vVIWbVNOpX3FRyS1pLMqaC2vUHLLWna7ESUoGCNnPK1geITzjU LJm8dm7vpPSGmUUoWzR6Q== X-UI-Out-Filterresults: notjunk:1; V01:K0:U0tfRNn3ass=:YTKPI4LAoza5mzaBbVsO8e b1dCo+7bSl3oxFUtK5WF0f+lkOeToG3jSZnih8wwlEGa4Cx7MGA8vIIXzVryNElrqFqyJQwbS WJ8eZwsx8hgH9aWYI5Z5NlJKAIsmUly6qUv+tyyO96FdKg7qwZPHa319rkNDS8jVkKQl7zk3Q zsyxpsr9R2BKD2xJt7Fk3sW6PV1a92bh6JELVxwGMdtydUYm5Issjj1ugOP8FYufkJdCI1eMZ P2ZUpLiwueiO51xhyzR1qeadQJpc3fyl55B8g0WQtgwXc53cOReER8hq4lIhVl/URDDWDPeXU v/qeL9DXMzl2Rdq9skmqjXtdUA3oYS6zT9d+bbnqGYLEdst8GvsoM2ugUgP+S4NC3ZEkxzjkh o0PDjbk4emlVFLzvV8BsvqGbg/iy3gdqX9dj98P6Jze+B4Sc/Je5Qfix46Kk2dpyPM0tY9D73 5D5GXnRWZB8byPOe0vV3Us6xxaFZF48P33iYC6f9G06inkan0LYB1XfCnVYD28RNocxHDAz2w MH/QLxKXHi2xMIeTf1IH78+3MbEWpE7YMZu1e7M50MRYtlNuiDGj/RKFKuK6g0hTQmykmOkn6 xkv7/lewsdE1tUuq7UT6AF/jc9zSSIdlBuNI+69+Bx6gxdP6zXyyi7/wTGSFZn/c0zYDoTtwx ya6FqNik38moRviCaC2kKbK133Xv85mXjwPptSHFTgIx63cUafeY/QgqXGaemppUwaF0PbbiT PuqM8ryfZPK/+C5E/+yaElxZyoD3VaXb3FttUA== Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP While experimenting with older compiler versions, I ran into a warning that no longer shows up on gcc-4.8 or newer: drivers/media/platform/s3c-camif/camif-capture.c: In function '__camif_subdev_try_format': drivers/media/platform/s3c-camif/camif-capture.c:1265:25: error: array subscript is below array bounds This is an off-by-one bug, leading to an access before the start of the array, while newer compilers silently assume this undefined behavior cannot happen and leave the loop at index 0 if no other entry matches. As Sylvester explains, we actually need to ensure that the value is within the range, so this reworks the loop to be easier to parse correctly, and an additional check to fall back on the first format value for any unexpected input. I found an existing gcc bug for it and added a reduced version of the function there. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69249#c3 Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface") Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Acked-by: Sakari Ailus --- v4: simplify a bit v3: fix newly introduced off-by-one bug. v2: rework logic rather than removing it. --- drivers/media/platform/s3c-camif/camif-capture.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/s3c-camif/camif-capture.c b/drivers/media/platform/s3c-camif/camif-capture.c index 437395a61065..9ab8e7ee2e1e 100644 --- a/drivers/media/platform/s3c-camif/camif-capture.c +++ b/drivers/media/platform/s3c-camif/camif-capture.c @@ -1256,16 +1256,17 @@ static void __camif_subdev_try_format(struct camif_dev *camif, { const struct s3c_camif_variant *variant = camif->variant; const struct vp_pix_limits *pix_lim; - int i = ARRAY_SIZE(camif_mbus_formats); + unsigned int i; /* FIXME: constraints against codec or preview path ? */ pix_lim = &variant->vp_pix_limits[VP_CODEC]; - while (i-- >= 0) + for (i = 0; i < ARRAY_SIZE(camif_mbus_formats); i++) if (camif_mbus_formats[i] == mf->code) break; - mf->code = camif_mbus_formats[i]; + if (i == ARRAY_SIZE(camif_mbus_formats)) + mf->code = camif_mbus_formats[0]; if (pad == CAMIF_SD_PAD_SINK) { v4l_bound_align_image(&mf->width, 8, CAMIF_MAX_PIX_WIDTH,