From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Carpenter Subject: Re: drm_edid: potential range checking issue? Date: Fri, 7 May 2010 10:35:42 +0200 Message-ID: <20100507083541.GV27064@bicker> References: <20100328112558.GM5069@bicker> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20100328112558.GM5069@bicker> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.sourceforge.net To: dri-devel@lists.sourceforge.net, ajax@redhat.com List-Id: dri-devel@lists.freedesktop.org Ping. This off-by-one overflow is still there in -next. I'm not sure how to fix it because both the declaraion and the use in add_detailed_modes() look deliberate. regards, dan carpenter On Sun, Mar 28, 2010 at 02:25:58PM +0300, Dan Carpenter wrote: > Hi list, :) > > Just going through some Smatch warnings. > > drivers/gpu/drm/drm_edid.c +1032 add_detailed_modes() 'data->data.timings' 5 <= 5 > 1027 /* Six modes per detailed section */ > 1028 for (i = 0; i < 6; i++) { > 1029 struct std_timing *std; > 1030 struct drm_display_mode *newmode; > 1031 > 1032 std = &data->data.timings[i]; > ^^^^^^^^^^^^^^^^^^^^^^ > > In include/drm/drm_edid.h this array has 5 elements not 6. > > struct detailed_non_pixel { > u8 pad1; > u8 type; /* ff=serial, fe=string, fd=monitor range, fc=monitor name > fb=color point data, fa=standard timing data, > f9=undefined, f8=mfg. reserved */ > u8 pad2; > union { > struct detailed_data_string str; > struct detailed_data_monitor_range range; > struct detailed_data_wpindex color; > struct std_timing timings[5]; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > struct cvt_timing cvt[4]; > } data; > } __attribute__((packed)); > > regards, > dan carpenter ------------------------------------------------------------------------------ --