All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Luotao Fu <l.fu@pengutronix.de>
Cc: socketcan-users@lists.berlios.de,
	Michael Olbrich <m.olbrich@pengutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv	less restrictive
Date: Fri, 07 Aug 2009 06:08:59 +0200	[thread overview]
Message-ID: <4A7BA8DB.2030102@hartkopp.net> (raw)
In-Reply-To: <20090806210230.GA22418@pengutronix.de>

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


  reply	other threads:[~2009-08-07  4:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06 15:24 [PATCH] CAN: make checking in can_rcv less restrictive Luotao Fu
2009-08-06 16:48 ` [Socketcan-users] " Oliver Hartkopp
2009-08-06 20:17   ` Luotao Fu
2009-08-06 20:58     ` Oliver Hartkopp
2009-08-06 21:02     ` Luotao Fu
2009-08-07  4:08       ` Oliver Hartkopp [this message]
2009-08-07  6:52   ` Rémi Denis-Courmont
2009-08-07 11:35     ` Oliver Hartkopp
2009-08-07 11:46       ` Luotao Fu
2009-08-07 11:54       ` Rémi Denis-Courmont

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A7BA8DB.2030102@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=l.fu@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.olbrich@pengutronix.de \
    --cc=socketcan-users@lists.berlios.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.