kernel.git/drivers/net/can/usb, branch linux-5.16.y

can: etas_es58x: es58x_fd_rx_event_msg(): initialize rx_event_msg before calling es58x_check_msg_len()

2022-04-13T18:03:06Z

[ Upstream commit 7a8cd7c0ee823a1cc893ab3feaa23e4b602bfb9a ] Function es58x_fd_rx_event() invokes the es58x_check_msg_len() macro: | ret = es58x_check_msg_len(es58x_dev->dev, *rx_event_msg, msg_len); While doing so, it dereferences an uninitialized variable: *rx_event_msg. This is actually harmless because es58x_check_msg_len() only uses preprocessor macros (sizeof() and __stringify()) on *rx_event_msg. c.f. [1]. Nonetheless, this pattern is confusing so the lines are reordered to make sure that rx_event_msg is correctly initialized. This patch also fixes a false positive warning reported by cppcheck: | cppcheck possible warnings: (new ones prefixed by >>, may not be real problems) | | In file included from drivers/net/can/usb/etas_es58x/es58x_fd.c: | >> drivers/net/can/usb/etas_es58x/es58x_fd.c:174:8: warning: Uninitialized variable: rx_event_msg [uninitvar] | ret = es58x_check_msg_len(es58x_dev->dev, *rx_event_msg, msg_len); | ^ [1] https://elixir.bootlin.com/linux/v5.16/source/drivers/net/can/usb/etas_es58x/es58x_core.h#L467 Link: https://lore.kernel.org/all/20220306101302.708783-1-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: mcba_usb: properly check endpoint type

2022-04-08T12:06:49Z

commit 136bed0bfd3bc9c95c88aafff2d22ecb3a919f23 upstream. Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. We should check that in endpoint is actually present to prevent this warning. Found pipes are now saved to struct mcba_priv and code uses them directly instead of making pipes in place. Fail log: | usb 5-1: BOGUS urb xfer, pipe 3 != type 1 | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | Modules linked in: | CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0 | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 | Workqueue: usb_hub_wq hub_event | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | ... | Call Trace: | | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline] | mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858 | usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 | call_driver_probe drivers/base/dd.c:517 [inline] Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/all/20220313100903.10868-1-paskripkin@gmail.com Reported-and-tested-by: syzbot+3bc1dce0cc0052d60fde@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Reviewed-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: mcba_usb: mcba_usb_start_xmit(): fix double dev_kfree_skb in error path

2022-04-08T12:06:49Z

commit 04c9b00ba83594a29813d6b1fb8fdc93a3915174 upstream. There is no need to call dev_kfree_skb() when usb_submit_urb() fails because can_put_echo_skb() deletes original skb and can_free_echo_skb() deletes the cloned skb. Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/all/20220311080208.45047-1-hbh25y@gmail.com Signed-off-by: Hangyu Hua Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: usb_8dev: usb_8dev_start_xmit(): fix double dev_kfree_skb() in error path

2022-04-08T12:05:24Z

commit 3d3925ff6433f98992685a9679613a2cc97f3ce2 upstream. There is no need to call dev_kfree_skb() when usb_submit_urb() fails because can_put_echo_skb() deletes original skb and can_free_echo_skb() deletes the cloned skb. Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices") Link: https://lore.kernel.org/all/20220311080614.45229-1-hbh25y@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Hangyu Hua Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: ems_usb: ems_usb_start_xmit(): fix double dev_kfree_skb() in error path

2022-04-08T12:05:24Z

commit c70222752228a62135cee3409dccefd494a24646 upstream. There is no need to call dev_kfree_skb() when usb_submit_urb() fails beacause can_put_echo_skb() deletes the original skb and can_free_echo_skb() deletes the cloned skb. Link: https://lore.kernel.org/all/20220228083639.38183-1-hbh25y@gmail.com Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Cc: stable@vger.kernel.org Cc: Sebastian Haas Signed-off-by: Hangyu Hua Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: etas_es58x: change opened_channel_cnt's type from atomic_t to u8

2022-03-08T18:14:14Z

[ Upstream commit f4896248e9025ff744b4147e6758274a1cb8cbae ] The driver uses an atomic_t variable: struct es58x_device::opened_channel_cnt to keep track of the number of opened channels in order to only allocate memory for the URBs when this count changes from zero to one. While the intent was to prevent race conditions, the choice of an atomic_t turns out to be a bad idea for several reasons: - implementation is incorrect and fails to decrement opened_channel_cnt when the URB allocation fails as reported in [1]. - even if opened_channel_cnt were to be correctly decremented, atomic_t is insufficient to cover edge cases: there can be a race condition in which 1/ a first process fails to allocate URBs memory 2/ a second process enters es58x_open() before the first process does its cleanup and decrements opened_channed_cnt. In which case, the second process would successfully return despite the URBs memory not being allocated. - actually, any kind of locking mechanism was useless here because it is redundant with the network stack big kernel lock (a.k.a. rtnl_lock) which is being hold by all the callers of net_device_ops:ndo_open() and net_device_ops:ndo_close(). c.f. the ASSERST_RTNL() calls in __dev_open() [2] and __dev_close_many() [3]. The atmomic_t is thus replaced by a simple u8 type and the logic to increment and decrement es58x_device:opened_channel_cnt is simplified accordingly fixing the bug reported in [1]. We do not check again for ASSERST_RTNL() as this is already done by the callers. [1] https://lore.kernel.org/linux-can/20220201140351.GA2548@kili/T/#u [2] https://elixir.bootlin.com/linux/v5.16/source/net/core/dev.c#L1463 [3] https://elixir.bootlin.com/linux/v5.16/source/net/core/dev.c#L1541 Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces") Link: https://lore.kernel.org/all/20220212112713.577957-1-mailhol.vincent@wanadoo.fr Reported-by: Dan Carpenter Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: gs_usb: change active_channels's type from atomic_t to u8

2022-03-08T18:14:11Z

commit 035b0fcf02707d3c9c2890dc1484b11aa5335eb1 upstream. The driver uses an atomic_t variable: gs_usb:active_channels to keep track of the number of opened channels in order to only allocate memory for the URBs when this count changes from zero to one. However, the driver does not decrement the counter when an error occurs in gs_can_open(). This issue is fixed by changing the type from atomic_t to u8 and by simplifying the logic accordingly. It is safe to use an u8 here because the network stack big kernel lock (a.k.a. rtnl_mutex) is being hold. For details, please refer to [1]. [1] https://lore.kernel.org/linux-can/CAMZ6Rq+sHpiw34ijPsmp7vbUpDtJwvVtdV7CvRZJsLixjAFfrg@mail.gmail.com/T/#t Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/all/20220214234814.1321599-1-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: do not increase rx statistics when generating a CAN rx error message frame

2022-01-27T11:02:30Z

[ Upstream commit 676068db69b847f06fe054fca15bf6b107bd24da ] The CAN error message frames (i.e. error skb) are an interface specific to socket CAN. The payload of the CAN error message frames does not correspond to any actual data sent on the wire. Only an error flag and a delimiter are transmitted when an error occurs (c.f. ISO 11898-1 section 10.4.4.2 "Error flag"). For this reason, it makes no sense to increment the rx_packets and rx_bytes fields of struct net_device_stats because no actual payload were transmitted on the wire. This patch fixes all the CAN drivers. Link: https://lore.kernel.org/all/20211207121531.42941-2-mailhol.vincent@wanadoo.fr CC: Marc Kleine-Budde CC: Nicolas Ferre CC: Alexandre Belloni CC: Ludovic Desroches CC: Chandrasekar Ramakrishnan CC: Maxime Ripard CC: Chen-Yu Tsai CC: Jernej Skrabec CC: Appana Durga Kedareswara rao CC: Naga Sureshkumar Relli CC: Michal Simek CC: Stephane Grosjean Tested-by: Jimmy Assarsson # kvaser Signed-off-by: Vincent Mailhol Acked-by: Stefan Mätje # esd_usb2 Tested-by: Stefan Mätje # esd_usb2 Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: gs_usb: gs_can_start_xmit(): zero-initialize hf->{flags,reserved}

2022-01-16T08:11:14Z

commit 89d58aebe14a365c25ba6645414afdbf4e41cea4 upstream. No information is deliberately sent in hf->flags in host -> device communications, but the open-source candleLight firmware echoes it back, which can result in the GS_CAN_FLAG_OVERFLOW flag being set and generating spurious ERRORFRAMEs. While there also initialize the reserved member with 0. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/all/20220106002952.25883-1-brian.silverman@bluerivertech.com Link: https://github.com/candle-usb/candleLight_fw/issues/87 Cc: stable@vger.kernel.org Signed-off-by: Brian Silverman [mkl: initialize the reserved member, too] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: gs_usb: fix use of uninitialized variable, detach device on reception of invalid USB data

2022-01-16T08:11:14Z

commit 4a8737ff068724f509d583fef404d349adba80d6 upstream. The received data contains the channel the received data is associated with. If the channel number is bigger than the actual number of channels assume broken or malicious USB device and shut it down. This fixes the error found by clang: | drivers/net/can/usb/gs_usb.c:386:6: error: variable 'dev' is used | uninitialized whenever 'if' condition is true | if (hf->channel >= GS_MAX_INTF) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | drivers/net/can/usb/gs_usb.c:474:10: note: uninitialized use occurs here | hf, dev->gs_hf_size, gs_usb_receive_bulk_callback, | ^~~ Link: https://lore.kernel.org/all/20211210091158.408326-1-mkl@pengutronix.de Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman