From patchwork Tue Jan 16 16:47:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 10167637 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 24324603B5 for ; Tue, 16 Jan 2018 16:48:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 140AA20CCF for ; Tue, 16 Jan 2018 16:48:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 08DB2212E8; Tue, 16 Jan 2018 16:48:05 +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=unavailable 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 8A49D20CCF for ; Tue, 16 Jan 2018 16:48:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750925AbeAPQrw (ORCPT ); Tue, 16 Jan 2018 11:47:52 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:51400 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbeAPQrv (ORCPT ); Tue, 16 Jan 2018 11:47:51 -0500 Received: from wuerfel.lan ([95.208.111.237]) by mrelayeu.kundenserver.de (mreue102 [212.227.15.145]) with ESMTPA (Nemesis) id 0Lz2sS-1exg0k448G-0149gB; Tue, 16 Jan 2018 17:47:43 +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] [v3] media: s3c-camif: fix out-of-bounds array access Date: Tue, 16 Jan 2018 17:47:24 +0100 Message-Id: <20180116164740.2097257-1-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 X-Provags-ID: V03:K0:7ergyklWddkpPxi0scU3axJMItWDYUhEXLlDt/qDIhNOmUVQAyz YIcaJUxI3Eg5hI2XeKwrxm5p85Oc4mOpv3AA86EQEOaTJdZeJUvNQKbH/ss3nCa4hsBfTbK KR7cxH34c7KN3A2hnfxBDdzjV4xCzdj5FybbZaEOWRlwSVnank4iC1AmdyRBB1PGPM3JH6m KY2ZbPjmcMfd24R1H4D3A== X-UI-Out-Filterresults: notjunk:1; V01:K0:bjAshMh6qvs=:ypkwFH9NrWgYZZeehc3SsT F/6jycpPTs3XfIITH+EXvf7ugvLoTm+nWFl4SrRkM2ClhmfUdAq9rWWRY15X5/Gy6kGZKX7xb rOy9ZBYPg4sovn4l4vlxZC1AAFC5K5NaT0ONtCn7njvQIFUG9HWKoDwVt95IUx3E8y6T7nzVO 5tVneix/wmQFB4rhex5Zis+Rcia92UIiF3RyfXKZDeaq6BbPmLLvEIMAZSsA/iXAoApIdoEWX qi9L7gHvWPKO+y5KyvKjAkILlSFgWWhB50jnu1vTIy+vFWkoH8cTE2+LuoUfyUz2Nx+pCsi+j V1EdppD8MVr/O2R7rIYydjlJZfxotWkMOsP7yShOoXlNgQ3Dq7dW7ZPyt383CgoHKOB7S0Hk4 ypAxfB/1ITHsZs32m5aTWHj6nwdVDM5XJ2yy4bYybanQTGBrkPKiLyCYTYocXXAIcrxNxP9bH OG4Ie0gsqHDbfGeUod9gXui2A7X9Jr70MEkrt5MPrWn71qv3xU3e5voDUw6WwicVXrqEIjKNI q/AcoBiMzIMYTb8Te5U3Qq6MsvdbDXD5dCAvpbb+26K10nGmg6b8+Wg0m94f1LcAQ+V90OwgV Xje7wMGL2c0dLXo869mLzd61wIzlfHQVu920fjM5fyxDZhHsApHhBi0uT3a5hngDOAPnv2JeF I5RFQFNmORDysokM6/j2NaZ/s9q40FctqQxT2lAFzqTSmznwxkj5eGmbGqJ6FegjNiUJmpvit W5omiOc0f2vNb1LjY38+P7nrM64DAJOpOmOe5A== Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@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 Acked-by: Sakari Ailus --- v3: fix newly introduced off-by-one bug. v2: rework logic rather than removing it. --- drivers/media/platform/s3c-camif/camif-capture.c | 9 ++++++--- 1 file changed, 6 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..f51b92e94a32 100644 --- a/drivers/media/platform/s3c-camif/camif-capture.c +++ b/drivers/media/platform/s3c-camif/camif-capture.c @@ -1256,16 +1256,19 @@ 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); + 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]; + else + mf->code = camif_mbus_formats[i]; if (pad == CAMIF_SD_PAD_SINK) { v4l_bound_align_image(&mf->width, 8, CAMIF_MAX_PIX_WIDTH,