lkml.org 
[lkml]   [2009]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Socketcan-users] [PATCH] CAN: make checking in can_rcv less restrictive
Luotao Fu wrote:
> Hi Oliver (again ;-)),
>
> On Thu, Aug 06, 2009 at 10:17:40PM +0200, Luotao Fu wrote:
>> Hi Oliver,
>>
>> On Thu, Aug 06, 2009 at 06:48:23PM +0200, Oliver Hartkopp wrote:
> ....
>>> When this BUG() triggers, someone provided a definitely broken *CAN* network
>>> driver, and this needsfp to be fixed on that level.
>> In our case a sender (a FPGA) generates correct can frames carrying
>> wrong dlc length. This way the can driver on our side runs into the bug
>> though the driver itself is allright. The opposite needed to be fixed,
>> not our side. Though we do suffer a system crash only because the
>> sender sends trash into the can network. This is imo quite bad.
>>
>
> /me answering myself
> had a closer look again. Seemed you are right. The can driver should
> have get the can_dlc right prior to passing the message a level higher.

Hi Luotao,

just one additional point i discovered after sending my last reply:

When can_dlc is not in the CAN conform value range from 0..8, you can really
get into trouble when accessing the CAN frames payload by using the can_dlc as
an index (a usual use-case):

for (i = 0; i < frame.can_dlc; i++) {
my_userdata[i] = frame.data[i];
printf("%02X ", frame.data[i]);
}

In this case you might access values outside the data[8] array.

And this is definitely a bad idea when you're writing to my_userdata[].

Best regards,
Oliver



\
 
 \ /
  Last update: 2009-08-07 06:11    [W:0.146 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site