linux-kernel - [PATCH 3.16 012/328] media: omap3isp: zero-initialize the isp cam

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <lsq.1544392233.725064728@decadent.org.uk>
Date:   Sun, 09 Dec 2018 21:50:33 +0000
From:   Ben Hutchings <ben@...adent.org.uk>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:     akpm@...ux-foundation.org,
        "Mauro Carvalho Chehab" <mchehab+samsung@...nel.org>,
        "Sebastian Reichel" <sebastian.reichel@...labora.co.uk>,
        "Javier Martinez Canillas" <javierm@...hat.com>,
        "Sakari Ailus" <sakari.ailus@...ux.intel.com>
Subject: [PATCH 3.16 012/328] media: omap3isp: zero-initialize the isp
 cam_xclk{a,b} initial data

3.16.62-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Javier Martinez Canillas <javierm@...hat.com>

commit 2ec7debd44b49927a6e2861521994cc075a389ed upstream.

The struct clk_init_data init variable is declared in the isp_xclk_init()
function so is an automatic variable allocated in the stack. But it's not
explicitly zero-initialized, so some init fields are left uninitialized.

This causes the data structure to have undefined values that may confuse
the common clock framework when the clock is registered.

For example, the uninitialized .flags field could have the CLK_IS_CRITICAL
bit set, causing the framework to wrongly prepare the clk on registration.
This leads to the isp_xclk_prepare() callback being called, which in turn
calls to the omap3isp_get() function that increments the isp dev refcount.

Since this omap3isp_get() call is unexpected, this leads to an unbalanced
omap3isp_get() call that prevents the requested IRQ to be later enabled,
due the refcount not being 0 when the correct omap3isp_get() call happens.

Fixes: 9b28ee3c9122 ("[media] omap3isp: Use the common clock framework")

Signed-off-by: Javier Martinez Canillas <javierm@...hat.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@...labora.co.uk>
Signed-off-by: Sakari Ailus <sakari.ailus@...ux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 drivers/media/platform/omap3isp/isp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -282,7 +282,7 @@ static const char *isp_xclk_parent_name
 static int isp_xclk_init(struct isp_device *isp)
 {
 	struct isp_platform_data *pdata = isp->pdata;
-	struct clk_init_data init;
+	struct clk_init_data init = { 0 };
 	unsigned int i;

 	for (i = 0; i < ARRAY_SIZE(isp->xclks); ++i)