Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv lessrestrictive

[Oliver Hartkopp]

Luotao Fu wrote:
> From: Michael Olbrich <m.olbrich@xxxxxxxxxxxxxx>
> 
> Checking for can frame format in can_rcv() is too restrictive. BUG_ON is way too
> heavy for the case that the can interface probably received a can frame with
> malicious format. Further it can be used for DDOS attack since BUG_ON can lead
> to kernel panic. Hence we turn this to WARN_ON instead.
> 
> Signed-off-by: Michael Olbrich <m.olbrich@xxxxxxxxxxxxxx>
> Signed-off-by: Luotao Fu <l.fu@xxxxxxxxxxxxxx>
> ---
>  net/can/af_can.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/net/can/af_can.c b/net/can/af_can.c
> index e733725..e6dcf4b 100644
> --- a/net/can/af_can.c
> +++ b/net/can/af_can.c
> @@ -656,7 +656,7 @@ static int can_rcv(struct sk_buff *skb, struct net_device *dev,
>  		return 0;
>  	}
>  
> -	BUG_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8);
> +	WARN_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8);
>  
>  	/* update statistics */
>  	can_stats.rx_frames++;

NAK.

The CAN applications can rely on getting proper CAN frames with this check. It
was introduced some time ago together with several other sanity checks - even
on the TX path.

The CAN core *only* consumes skbuffs originated from a CAN netdevice
(ARPHRD_CAN).

When this BUG() triggers, someone provided a definitely broken *CAN* network
driver, and this needs to be fixed on that level. It is really not that
problematic to ensure proper CAN frames on driver level ... this sanity check
should not be needed to be performed by every single application.

Btw. the SocketCAN core ML and probably the netdev ML are the better places to
post CAN specific stuff the first time.

Regards,
Oliver

ps. If you have a use-case to make a DDOS via CAN bus - please let me know.
I'm always interested doing strange things on CAN ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/