linux-kernel - Re: [Socketcan-users] [PATCH] CAN: make checking in can

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 06 Aug 2009 18:48:23 +0200
From:	Oliver Hartkopp <oliver@...tkopp.net>
To:	Luotao Fu <l.fu@...gutronix.de>
CC:	socketcan-users@...ts.berlios.de,
	Michael Olbrich <m.olbrich@...gutronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv less
 restrictive

Luotao Fu wrote:
> From: Michael Olbrich <m.olbrich@...gutronix.de>
> 
> 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@...gutronix.de>
> Signed-off-by: Luotao Fu <l.fu@...gutronix.de>
> ---
>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/