linux-stable.git/net/can, branch linux-3.16.y

can: purge socket error queue on sock destruct

2019-10-05T15:19:55+00:00

commit fd704bd5ee749d560e86c4f1fd2ef486d8abf7cf upstream.

CAN supports software tx timestamps as of the below commit. Purge
any queued timestamp packets on socket destroy.

Fixes: 51f31cabe3ce ("ip: support for TX timestamps on UDP and RAW sockets")
Reported-by: syzbot+a90604060cb40f5bdd16@syzkaller.appspotmail.com
Signed-off-by: Willem de Bruijn 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings

can: af_can: Fix error path of can_init()

2019-10-05T15:19:54+00:00

commit c5a3aed1cd3152429348ee1fe5cdcca65fe901ce upstream.

This patch add error path for can_init() to avoid possible crash if some
error occurs.

Fixes: 0d66548a10cb ("[CAN]: Add PF_CAN core module")
Signed-off-by: YueHaibing 
Acked-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
[bwh: Backported to 3.16:
 - af_can doesn't register any pernet_operations
 - It does start a global timer and add procfs entries that need to be
   cleaned up on the error path]
Signed-off-by: Ben Hutchings

can: bcm: check timer values before ktime conversion

2019-05-02T20:41:27+00:00

commit 93171ba6f1deffd82f381d36cb13177872d023f6 upstream.

Kyungtae Kim detected a potential integer overflow in bcm_[rx|tx]_setup()
when the conversion into ktime multiplies the given value with NSEC_PER_USEC
(1000).

Reference: https://marc.info/?l=linux-can&m=154732118819828&w=2

Add a check for the given tv_usec, so that the value stays below one second.
Additionally limit the tv_sec value to a reasonable value for CAN related
use-cases of 400 days and ensure all values to be positive.

Reported-by: Kyungtae Kim 
Tested-by: Oliver Hartkopp 
Signed-off-by: Oliver Hartkopp 
Tested-by: Kyungtae Kim 
Acked-by: Andre Naujoks 
Signed-off-by: Marc Kleine-Budde 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

can: gw: ensure DLC boundaries after CAN frame modification

2019-03-25T17:32:33+00:00

commit 0aaa81377c5a01f686bcdb8c7a6929a7bf330c68 upstream.

Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN
frame modification rule that makes the data length code a higher value than
the available CAN frame data size. In combination with a configured checksum
calculation where the result is stored relatively to the end of the data
(e.g. cgw_csum_xor_rel) the tail of the skb (e.g. frag_list pointer in
skb_shared_info) can be rewritten which finally can cause a system crash.

Michael Kubecek suggested to drop frames that have a DLC exceeding the
available space after the modification process and provided a patch that can
handle CAN FD frames too. Within this patch we also limit the length for the
checksum calculations to the maximum of Classic CAN data length (8).

CAN frames that are dropped by these additional checks are counted with the
CGW_DELETED counter which indicates misconfigurations in can-gw rules.

This fixes CVE-2019-3701.

Reported-by: Muyu Yu 
Reported-by: Marcus Meissner 
Suggested-by: Michal Kubecek 
Tested-by: Muyu Yu 
Tested-by: Oliver Hartkopp 
Signed-off-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

can: raw: check for CAN FD capable netdev in raw_sendmsg()

2019-02-11T17:53:56+00:00

commit a43608fa77213ad5ac5f75994254b9f65d57cfa0 upstream.

When the socket is CAN FD enabled it can handle CAN FD frame
transmissions.  Add an additional check in raw_sendmsg() as a CAN2.0 CAN
driver (non CAN FD) should never see a CAN FD frame. Due to the commonly
used can_dropped_invalid_skb() function the CAN 2.0 driver would drop
that CAN FD frame anyway - but with this patch the user gets a proper
-EINVAL return code.

Signed-off-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
[bwh: Backported to 3.16: Keep looking up devices in init_net]
Signed-off-by: Ben Hutchings

can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once

2018-03-03T15:52:26+00:00

commit d4689846881d160a4d12a514e991a740bcb5d65a upstream.

If an invalid CANFD frame is received, from a driver or from a tun
interface, a Kernel warning is generated.

This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.

Reported-by: syzbot+e3b775f40babeff6e68b@syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov 
Acked-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
[bwh: Backported to 3.16:
 - Keep using the 'drop' label, as it has another user
 - Adjust context]
Signed-off-by: Ben Hutchings

can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once

2018-03-03T15:52:26+00:00

commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.

If an invalid CAN frame is received, from a driver or from a tun
interface, a Kernel warning is generated.

This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.

Reported-by: syzbot+4386709c0c1284dca827@syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov 
Acked-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
[bwh: Backported to 3.16:
 - Keep using the 'drop' label, as it has another user
 - Adjust context]
Signed-off-by: Ben Hutchings

can: Fix kernel panic at security_sock_rcv_skb

2017-03-16T02:27:24+00:00

[ Upstream commit f1712c73714088a7252d276a57126d56c7d37e64 ]

Zhang Yanmin reported crashes [1] and provided a patch adding a
synchronize_rcu() call in can_rx_unregister()

The main problem seems that the sockets themselves are not RCU
protected.

If CAN uses RCU for delivery, then sockets should be freed only after
one RCU grace period.

Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
ease stable backports with the following fix instead.

[1]
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0

Call Trace:
 
 [] security_sock_rcv_skb+0x4c/0x60
 [] sk_filter+0x41/0x210
 [] sock_queue_rcv_skb+0x53/0x3a0
 [] raw_rcv+0x2a3/0x3c0
 [] can_rcv_filter+0x12b/0x370
 [] can_receive+0xd9/0x120
 [] can_rcv+0xab/0x100
 [] __netif_receive_skb_core+0xd8c/0x11f0
 [] __netif_receive_skb+0x24/0xb0
 [] process_backlog+0x127/0x280
 [] net_rx_action+0x33b/0x4f0
 [] __do_softirq+0x184/0x440
 [] do_softirq_own_stack+0x1c/0x30
 
 [] do_softirq.part.18+0x3b/0x40
 [] do_softirq+0x1d/0x20
 [] netif_rx_ni+0xe5/0x110
 [] slcan_receive_buf+0x507/0x520
 [] flush_to_ldisc+0x21c/0x230
 [] process_one_work+0x24f/0x670
 [] worker_thread+0x9d/0x6f0
 [] ? rescuer_thread+0x480/0x480
 [] kthread+0x12c/0x150
 [] ret_from_fork+0x3f/0x70

Reported-by: Zhang Yanmin 
Signed-off-by: Eric Dumazet 
Acked-by: Oliver Hartkopp 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

can: bcm: fix hrtimer/tasklet termination in bcm op removal

2017-03-16T02:27:07+00:00

commit a06393ed03167771246c4c43192d9c264bc48412 upstream.

When removing a bcm tx operation either a hrtimer or a tasklet might run.
As the hrtimer triggers its associated tasklet and vice versa we need to
take care to mutually terminate both handlers.

Reported-by: Michael Josenhans 
Signed-off-by: Oliver Hartkopp 
Tested-by: Michael Josenhans 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings

can: raw: raw_setsockopt: limit number of can_filter that can be set

2017-02-23T03:54:43+00:00

commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream.

This patch adds a check to limit the number of can_filters that can be
set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER
are not prevented resulting in a warning.

Reference: https://lkml.org/lkml/2016/12/2/230

Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings