Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1340875pxb; Fri, 13 Nov 2020 10:06:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNPq5MXNxkgHujhe+REK/R9X5OOJLSs4G9rkgSIfAJnEwXwJRoqnpwIyxvJSDd+ybn214F X-Received: by 2002:a17:906:26c6:: with SMTP id u6mr3265415ejc.349.1605290782574; Fri, 13 Nov 2020 10:06:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605290782; cv=none; d=google.com; s=arc-20160816; b=mLcqyfK7OtDCpTZfEp+zN09XWQm3DrHx7HmzvP+cMEScyIUvmTftY4P6X/yWwn7FFx 6bSOUGl0/m7GR0Gb8WvY37GlAil5os73yNvvQU8BPE0TX95KQs0xN69gkJ9fPboyOYA3 Ermi5LM8KApdsyfvBo3iIJE3m8Lu95zFoPNt5a8vyJA3ZmKoMI8VuZND1v5aGUthYsYZ OURsgl2LUxrVfb7tZY6Oq2FSgkqv/1feCXgnkrfvJOSWhn0pwG8U2I4hu5mdRbvFUgTF oo/6N4NpZwg3LQtaZc35cCECQHCBN8JMCkrtQZhpHJOVLxhP9IL/2ecE9KzwYGwpIOWU S5dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Jx6UFnRaEDLVJDkcpT5lcFjUdC7kmeLjIl9fn/59y8A=; b=o3GIGlU309X/M3PHn5y0uvN5rDtTGPM2IJkZ5l/Tx542V7cDvBLqv/w7Rgk27/kLPj FXEKdsD5NyQ50hwcO8KfhuZXx3sgzYje02g64GUjJa7ek1vIPpt8ZjsiCsgM52JnQyr6 7tlHE90cePN0eoVXZE2J0Ss9iQaW46b3FDa+fgypSKeh3joGdGF9flIZrVCQL4Gf3ca0 1Vx2BiNZZReyzEZMDGB+2MbHFYxBC906KhE7tCqtyfpq0UsqjWf8MKefHQ70Z7nrooJW AIxfpExZLY83dFfjyPxENczzeze+q3z12XKaCs0s3ec01K+1Q8mCuQ1f0pB7O9xS2rhH T4Ag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q24si3608111eju.589.2020.11.13.10.05.57; Fri, 13 Nov 2020 10:06:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726295AbgKMSCW (ORCPT + 99 others); Fri, 13 Nov 2020 13:02:22 -0500 Received: from asavdk3.altibox.net ([109.247.116.14]:56328 "EHLO asavdk3.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726064AbgKMSCW (ORCPT ); Fri, 13 Nov 2020 13:02:22 -0500 Received: from ravnborg.org (unknown [188.228.123.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk3.altibox.net (Postfix) with ESMTPS id F2C252001F; Fri, 13 Nov 2020 19:02:15 +0100 (CET) Date: Fri, 13 Nov 2020 19:02:14 +0100 From: Sam Ravnborg To: Colin Ian King Cc: Anitha Chrisanthus , Edmund Dea , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[] Message-ID: <20201113180214.GA3675629@ravnborg.org> References: <20201113120121.33212-1-colin.king@canonical.com> <20201113145557.GB3647624@ravnborg.org> <8dd5b960-d6c4-73cc-703e-349dc66f2937@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8dd5b960-d6c4-73cc-703e-349dc66f2937@canonical.com> X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=VbvZwmh9 c=1 sm=1 tr=0 a=S6zTFyMACwkrwXSdXUNehg==:117 a=S6zTFyMACwkrwXSdXUNehg==:17 a=kj9zAlcOel0A:10 a=DfNHnWVPAAAA:8 a=54tR-wWqPms2FSGqy7MA:9 a=CjuIK1q_8ugA:10 a=rjTVMONInIDnV1a_A2c_:22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Colin. On Fri, Nov 13, 2020 at 03:04:34PM +0000, Colin Ian King wrote: > On 13/11/2020 14:55, Sam Ravnborg wrote: > > Hi Colin. > > > > On Fri, Nov 13, 2020 at 12:01:21PM +0000, Colin King wrote: > >> From: Colin Ian King > >> > >> Writes to elements in the kmb->plane_status array in function > >> kmb_plane_atomic_disable are overrunning the array when plane_id is > >> more than 1 because currently the array is KMB_MAX_PLANES elements > >> in size and this is currently #defined as 1. Fix this by defining > >> KMB_MAX_PLANES to 4. > > > > I fail to follow you here. > > In kmb_plane_init() only one plane is allocated - with id set to 0. > > So for now only one plane is allocated thus kmb_plane_atomic_disable() > > is only called for this plane. > > > > With your change we will start allocating four planes, something that is > > not tested. > > > > Do I miss something? > > > > Sam > > > > The static analysis from coverity on linux-next suggested that there was > an array overflow as follows: > > 108 static void kmb_plane_atomic_disable(struct drm_plane *plane, > 109 struct drm_plane_state *state) > 110 { > > 1. Condition 0 /* !!(!__builtin_types_compatible_p() && > !__builtin_types_compatible_p()) */, taking false branch. > > 111 struct kmb_plane *kmb_plane = to_kmb_plane(plane); > > 2. assignment: Assigning: plane_id = kmb_plane->id. > > 112 int plane_id = kmb_plane->id; > 113 struct kmb_drm_private *kmb; > 114 > 115 kmb = to_kmb(plane->dev); > 116 > > 3. Switch case value LAYER_3. > > 117 switch (plane_id) { > 118 case LAYER_0: > 119 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE; > 120 break; With the current code this is the only case that hits. So coverity is right that if we hit other cases that would result in a bug. But kmb_plane->id will for now not have other values than 0. So it is a subtle false positive. There is some "dead" code here - but this is in preparation for more than one layer and we will keep the code for now, unless Anitha chimes in and says otherwise. Sam > 121 case LAYER_1: > > (#2 of 4): Out-of-bounds write (OVERRUN) > > 122 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE; > 123 break; > 124 case LAYER_2: > > (#3 of 4): Out-of-bounds write (OVERRUN) > > 125 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE; > 126 break; > > 4. equality_cond: Jumping to case LAYER_3. > > 127 case LAYER_3: > > (#1 of 4): Out-of-bounds write (OVERRUN) > 5. overrun-local: Overrunning array kmb->plane_status of 1 8-byte > elements at element index 3 (byte offset 31) using index plane_id (which > evaluates to 3). > > 128 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE; > 129 break; > 130 } > 131 > > (#4 of 4): Out-of-bounds write (OVERRUN) > > 132 kmb->plane_status[plane_id].disable = true; > 133 } > 134 > > So it seems the assignments to kmb->plane_status[plane_id] are > overrunning the array since plane_status is allocated as 1 element and > yet plane_id can be 0..3 > > I could be misunderstanding this, or it may be a false positive. > > Colin