1. 17 Jul, 2023 6 commits
    • Fedor Ross's avatar
      can: mcp251xfd: __mcp251xfd_chip_set_mode(): increase poll timeout · 9efa1a54
      Fedor Ross authored
      The mcp251xfd controller needs an idle bus to enter 'Normal CAN 2.0
      mode' or . The maximum length of a CAN frame is 736 bits (64 data
      bytes, CAN-FD, EFF mode, worst case bit stuffing and interframe
      spacing). For low bit rates like 10 kbit/s the arbitrarily chosen
      MCP251XFD_POLL_TIMEOUT_US of 1 ms is too small.
      
      Otherwise during polling for the CAN controller to enter 'Normal CAN
      2.0 mode' the timeout limit is exceeded and the configuration fails
      with:
      
      | $ ip link set dev can1 up type can bitrate 10000
      | [  731.911072] mcp251xfd spi2.1 can1: Controller failed to enter mode CAN 2.0 Mode (6) and stays in Configuration Mode (4) (con=0x068b0760, osc=0x00000468).
      | [  731.927192] mcp251xfd spi2.1 can1: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
      | [  731.938101] A link change request failed with some changes committed already. Interface can1 may have been left with an inconsistent configuration, please check.
      | RTNETLINK answers: Connection timed out
      
      Make MCP251XFD_POLL_TIMEOUT_US timeout calculation dynamic. Use
      maximum of 1ms and bit time of 1 full 64 data bytes CAN-FD frame in
      EFF mode, worst case bit stuffing and interframe spacing at the
      current bit rate.
      
      For easier backporting define the macro MCP251XFD_FRAME_LEN_MAX_BITS
      that holds the max frame length in bits, which is 736. This can be
      replaced by can_frame_bits(true, true, true, true, CANFD_MAX_DLEN) in
      a cleanup patch later.
      
      Fixes: 55e5b97f ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
      Signed-off-by: default avatarFedor Ross <fedor.ross@ifm.com>
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/all/20230717-mcp251xfd-fix-increase-poll-timeout-v5-1-06600f34c684@pengutronix.deSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      9efa1a54
    • Marc Kleine-Budde's avatar
      Merge patch series "can: gs_usb: fix time stamp counter initialization" · dc050849
      Marc Kleine-Budde authored
      Marc Kleine-Budde <mkl@pengutronix.de> says:
      
      During testing I noticed a crash if unloading/loading the gs_usb
      driver during high CAN bus load.
      
      The current version of the candlelight firmware doesn't flush the
      queues of the received CAN frames during the reset command. This leads
      to a crash if hardware timestamps are enabled, and an URB from the
      device is received before the cycle counter/time counter
      infrastructure has been setup.
      
      First clean up then error handling in gs_can_open().
      
      Then, fix the problem by converting the cycle counter/time counter
      infrastructure from a per-channel to per-device and set it up before
      submitting RX-URBs to the USB stack.
      
      Link: https://lore.kernel.org/all/20230716-gs_usb-fix-time-stamp-counter-v1-0-9017cefcd9d5@pengutronix.deSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      dc050849
    • Marc Kleine-Budde's avatar
      can: gs_usb: fix time stamp counter initialization · 5886e4d5
      Marc Kleine-Budde authored
      If the gs_usb device driver is unloaded (or unbound) before the
      interface is shut down, the USB stack first calls the struct
      usb_driver::disconnect and then the struct net_device_ops::ndo_stop
      callback.
      
      In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more
      RX'ed CAN frames are send from the USB device to the host. Later in
      gs_can_close() a reset control message is send to each CAN channel to
      remove the controller from the CAN bus. In this race window the USB
      device can still receive CAN frames from the bus and internally queue
      them to be send to the host.
      
      At least in the current version of the candlelight firmware, the queue
      of received CAN frames is not emptied during the reset command. After
      loading (or binding) the gs_usb driver, new URBs are submitted during
      the struct net_device_ops::ndo_open callback and the candlelight
      firmware starts sending its already queued CAN frames to the host.
      
      However, this scenario was not considered when implementing the
      hardware timestamp function. The cycle counter/time counter
      infrastructure is set up (gs_usb_timestamp_init()) after the USBs are
      submitted, resulting in a NULL pointer dereference if
      timecounter_cyc2time() (via the call chain:
      gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() ->
      gs_usb_skb_set_timestamp()) is called too early.
      
      Move the gs_usb_timestamp_init() function before the URBs are
      submitted to fix this problem.
      
      For a comprehensive solution, we need to consider gs_usb devices with
      more than 1 channel. The cycle counter/time counter infrastructure is
      setup per channel, but the RX URBs are per device. Once gs_can_open()
      of _a_ channel has been called, and URBs have been submitted, the
      gs_usb_receive_bulk_callback() can be called for _all_ available
      channels, even for channels that are not running, yet. As cycle
      counter/time counter has not set up, this will again lead to a NULL
      pointer dereference.
      
      Convert the cycle counter/time counter from a "per channel" to a "per
      device" functionality. Also set it up, before submitting any URBs to
      the device.
      
      Further in gs_usb_receive_bulk_callback(), don't process any URBs for
      not started CAN channels, only resubmit the URB.
      
      Fixes: 45dfa45f ("can: gs_usb: add RX and TX hardware timestamp support")
      Closes: https://github.com/candle-usb/candleLight_fw/issues/137#issuecomment-1623532076
      Cc: stable@vger.kernel.org
      Cc: John Whittington <git@jbrengineering.co.uk>
      Link: https://lore.kernel.org/all/20230716-gs_usb-fix-time-stamp-counter-v1-2-9017cefcd9d5@pengutronix.deSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      5886e4d5
    • Marc Kleine-Budde's avatar
      can: gs_usb: gs_can_open(): improve error handling · 2603be9e
      Marc Kleine-Budde authored
      The gs_usb driver handles USB devices with more than 1 CAN channel.
      The RX path for all channels share the same bulk endpoint (the
      transmitted bulk data encodes the channel number). These per-device
      resources are allocated and submitted by the first opened channel.
      
      During this allocation, the resources are either released immediately
      in case of a failure or the URBs are anchored. All anchored URBs are
      finally killed with gs_usb_disconnect().
      
      Currently, gs_can_open() returns with an error if the allocation of a
      URB or a buffer fails. However, if usb_submit_urb() fails, the driver
      continues with the URBs submitted so far, even if no URBs were
      successfully submitted.
      
      Treat every error as fatal and free all allocated resources
      immediately.
      
      Switch to goto-style error handling, to prepare the driver for more
      per-device resource allocation.
      
      Cc: stable@vger.kernel.org
      Cc: John Whittington <git@jbrengineering.co.uk>
      Link: https://lore.kernel.org/all/20230716-gs_usb-fix-time-stamp-counter-v1-1-9017cefcd9d5@pengutronix.deSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      2603be9e
    • YueHaibing's avatar
      can: bcm: Fix UAF in bcm_proc_show() · 55c3b960
      YueHaibing authored
      BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80
      Read of size 8 at addr ffff888155846230 by task cat/7862
      
      CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0xd5/0x150
       print_report+0xc1/0x5e0
       kasan_report+0xba/0xf0
       bcm_proc_show+0x969/0xa80
       seq_read_iter+0x4f6/0x1260
       seq_read+0x165/0x210
       proc_reg_read+0x227/0x300
       vfs_read+0x1d5/0x8d0
       ksys_read+0x11e/0x240
       do_syscall_64+0x35/0xb0
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Allocated by task 7846:
       kasan_save_stack+0x1e/0x40
       kasan_set_track+0x21/0x30
       __kasan_kmalloc+0x9e/0xa0
       bcm_sendmsg+0x264b/0x44e0
       sock_sendmsg+0xda/0x180
       ____sys_sendmsg+0x735/0x920
       ___sys_sendmsg+0x11d/0x1b0
       __sys_sendmsg+0xfa/0x1d0
       do_syscall_64+0x35/0xb0
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Freed by task 7846:
       kasan_save_stack+0x1e/0x40
       kasan_set_track+0x21/0x30
       kasan_save_free_info+0x27/0x40
       ____kasan_slab_free+0x161/0x1c0
       slab_free_freelist_hook+0x119/0x220
       __kmem_cache_free+0xb4/0x2e0
       rcu_core+0x809/0x1bd0
      
      bcm_op is freed before procfs entry be removed in bcm_release(),
      this lead to bcm_proc_show() may read the freed bcm_op.
      
      Fixes: ffd980f9 ("[CAN]: Add broadcast manager (bcm) protocol")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Link: https://lore.kernel.org/all/20230715092543.15548-1-yuehaibing@huawei.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      55c3b960
    • Ziyang Xuan's avatar
      can: raw: fix receiver memory leak · ee8b94c8
      Ziyang Xuan authored
      Got kmemleak errors with the following ltp can_filter testcase:
      
      for ((i=1; i<=100; i++))
      do
              ./can_filter &
              sleep 0.1
      done
      
      ==============================================================
      [<00000000db4a4943>] can_rx_register+0x147/0x360 [can]
      [<00000000a289549d>] raw_setsockopt+0x5ef/0x853 [can_raw]
      [<000000006d3d9ebd>] __sys_setsockopt+0x173/0x2c0
      [<00000000407dbfec>] __x64_sys_setsockopt+0x61/0x70
      [<00000000fd468496>] do_syscall_64+0x33/0x40
      [<00000000b7e47d51>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
      
      It's a bug in the concurrent scenario of unregister_netdevice_many()
      and raw_release() as following:
      
                   cpu0                                        cpu1
      unregister_netdevice_many(can_dev)
        unlist_netdevice(can_dev) // dev_get_by_index() return NULL after this
        net_set_todo(can_dev)
      						raw_release(can_socket)
      						  dev = dev_get_by_index(, ro->ifindex); // dev == NULL
      						  if (dev) { // receivers in dev_rcv_lists not free because dev is NULL
      						    raw_disable_allfilters(, dev, );
      						    dev_put(dev);
      						  }
      						  ...
      						  ro->bound = 0;
      						  ...
      
      call_netdevice_notifiers(NETDEV_UNREGISTER, )
        raw_notify(, NETDEV_UNREGISTER, )
          if (ro->bound) // invalid because ro->bound has been set 0
            raw_disable_allfilters(, dev, ); // receivers in dev_rcv_lists will never be freed
      
      Add a net_device pointer member in struct raw_sock to record bound
      can_dev, and use rtnl_lock to serialize raw_socket members between
      raw_bind(), raw_release(), raw_setsockopt() and raw_notify(). Use
      ro->dev to decide whether to free receivers in dev_rcv_lists.
      
      Fixes: 8d0caedb ("can: bcm/raw/isotp: use per module netdevice notifier")
      Reviewed-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Link: https://lore.kernel.org/all/20230711011737.1969582-1-william.xuanziyang@huawei.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      ee8b94c8
  2. 15 Jul, 2023 10 commits
  3. 14 Jul, 2023 9 commits
  4. 13 Jul, 2023 15 commits