1. 27 Jul, 2021 4 commits
    • Yufeng Mo's avatar
      net: hns3: change the method of obtaining default ptp cycle · 8373cd38
      Yufeng Mo authored
      The ptp cycle is related to the hardware, so it may cause compatibility
      issues if a fixed value is used in driver. Therefore, the method of
      obtaining this value is changed to read from the register rather than
      use a fixed value in driver.
      
      Fixes: 0bf5eb78 ("net: hns3: add support for PTP")
      Signed-off-by: default avatarYufeng Mo <moyufeng@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8373cd38
    • Tang Bin's avatar
      nfc: s3fwrn5: fix undefined parameter values in dev_err() · 801e541c
      Tang Bin authored
      In the function s3fwrn5_fw_download(), the 'ret' is not assigned,
      so the correct value should be given in dev_err function.
      
      Fixes: a0302ff5 ("nfc: s3fwrn5: remove unnecessary label")
      Signed-off-by: default avatarZhang Shengju <zhangshengju@cmss.chinamobile.com>
      Signed-off-by: default avatarTang Bin <tangbin@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      801e541c
    • Pavel Skripkin's avatar
      net: llc: fix skb_over_panic · c7c9d210
      Pavel Skripkin authored
      Syzbot reported skb_over_panic() in llc_pdu_init_as_xid_cmd(). The
      problem was in wrong LCC header manipulations.
      
      Syzbot's reproducer tries to send XID packet. llc_ui_sendmsg() is
      doing following steps:
      
      	1. skb allocation with size = len + header size
      		len is passed from userpace and header size
      		is 3 since addr->sllc_xid is set.
      
      	2. skb_reserve() for header_len = 3
      	3. filling all other space with memcpy_from_msg()
      
      Ok, at this moment we have fully loaded skb, only headers needs to be
      filled.
      
      Then code comes to llc_sap_action_send_xid_c(). This function pushes 3
      bytes for LLC PDU header and initializes it. Then comes
      llc_pdu_init_as_xid_cmd(). It initalizes next 3 bytes *AFTER* LLC PDU
      header and call skb_push(skb, 3). This looks wrong for 2 reasons:
      
      	1. Bytes rigth after LLC header are user data, so this function
      	   was overwriting payload.
      
      	2. skb_push(skb, 3) call can cause skb_over_panic() since
      	   all free space was filled in llc_ui_sendmsg(). (This can
      	   happen is user passed 686 len: 686 + 14 (eth header) + 3 (LLC
      	   header) = 703. SKB_DATA_ALIGN(703) = 704)
      
      So, in this patch I added 2 new private constansts: LLC_PDU_TYPE_U_XID
      and LLC_PDU_LEN_U_XID. LLC_PDU_LEN_U_XID is used to correctly reserve
      header size to handle LLC + XID case. LLC_PDU_TYPE_U_XID is used by
      llc_pdu_header_init() function to push 6 bytes instead of 3. And finally
      I removed skb_push() call from llc_pdu_init_as_xid_cmd().
      
      This changes should not affect other parts of LLC, since after
      all steps we just transmit buffer.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-and-tested-by: syzbot+5e5a981ad7cc54c4b2b4@syzkaller.appspotmail.com
      Signed-off-by: default avatarPavel Skripkin <paskripkin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7c9d210
    • Sunil Goutham's avatar
      octeontx2-af: Do NIX_RX_SW_SYNC twice · fcef709c
      Sunil Goutham authored
      NIX_RX_SW_SYNC ensures all existing transactions are finished and
      pkts are written to LLC/DRAM, queues should be teared down after
      successful SW_SYNC. Due to a HW errata, in some rare scenarios
      an existing transaction might end after SW_SYNC operation. To
      ensure operation is fully done, do the SW_SYNC twice.
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fcef709c
  2. 26 Jul, 2021 4 commits
  3. 25 Jul, 2021 10 commits
  4. 24 Jul, 2021 9 commits
    • Michael Chan's avatar
      bnxt_en: Add missing periodic PHC overflow check · 89bc7f45
      Michael Chan authored
      We use the timecounter APIs for the 48-bit PHC and packet timestamps.
      We must periodically update the timecounter at roughly half the
      overflow interval.  The overflow interval is about 78 hours, so
      update it every 19 hours (1/4 interval) for some extra margins.
      
      Fixes: 390862f4 ("bnxt_en: Get the full 48-bit hardware timestamp periodically")
      Reviewed-by: default avatarPavan Chebbi <pavan.chebbi@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89bc7f45
    • Xin Long's avatar
      tipc: do not write skb_shinfo frags when doing decrytion · 3cf4375a
      Xin Long authored
      One skb's skb_shinfo frags are not writable, and they can be shared with
      other skbs' like by pskb_copy(). To write the frags may cause other skb's
      data crash.
      
      So before doing en/decryption, skb_cow_data() should always be called for
      a cloned or nonlinear skb if req dst is using the same sg as req src.
      While at it, the likely branch can be removed, as it will be covered
      by skb_cow_data().
      
      Note that esp_input() has the same issue, and I will fix it in another
      patch. tipc_aead_encrypt() doesn't have this issue, as it only processes
      linear data in the unlikely branch.
      
      Fixes: fc1b6d6d ("tipc: introduce TIPC encryption & authentication")
      Reported-by: default avatarShuang Li <shuali@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3cf4375a
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-5.14-20210724' of... · e394f1e3
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-5.14-20210724' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      linux-can-fixes-for-5.14-20210724
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2021-07-24
      
      this is a pull request of 6 patches for net/master.
      
      The first patch is by Joakim Zhang targets the imx8mp device tree. It
      removes the imx6 fallback from the flexcan binding, as the imx6 is not
      compatible with the imx8mp.
      
      Ziyang Xuan contributes a patch to fix a use-after-free in the CAN
      raw's raw_setsockopt().
      
      The next two patches target the CAN J1939 protocol. The first one is
      by Oleksij Rempel and clarifies the lifetime of session object in
      j1939_session_deactivate(). Zhang Changzhong's patch fixes the timeout
      value between consecutive TP.DT.
      
      Stephane Grosjean contributes a patch for the peak_usb driver to fix
      reading of the rxerr/txerr values.
      
      The last patch is by me for the mcp251xfd driver. It stops the
      timestamp worker in case of a fatal error in the IRQ handler.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e394f1e3
    • Marc Kleine-Budde's avatar
      can: mcp251xfd: mcp251xfd_irq(): stop timestamping worker in case error in IRQ · ef68a717
      Marc Kleine-Budde authored
      In case an error occurred in the IRQ handler, the chip status is
      dumped via devcoredump and all IRQs are disabled, but the chip stays
      powered for further analysis.
      
      The chip is in an undefined state and will not receive any CAN frames,
      so shut down the timestamping worker, which reads the TBC register
      regularly, too. This avoids any CRC read error messages if there is a
      communication problem with the chip.
      
      Fixes: efd8d98d ("can: mcp251xfd: add HW timestamp infrastructure")
      Link: https://lore.kernel.org/r/20210724155131.471303-1-mkl@pengutronix.deSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      ef68a717
    • Stephane Grosjean's avatar
      can: peak_usb: pcan_usb_handle_bus_evt(): fix reading rxerr/txerr values · 590eb2b7
      Stephane Grosjean authored
      This patch fixes an incorrect way of reading error counters in messages
      received for this purpose from the PCAN-USB interface. These messages
      inform about the increase or decrease of the error counters, whose values
      are placed in bytes 1 and 2 of the message data (not 0 and 1).
      
      Fixes: ea8b33bd ("can: pcan_usb: add support of rxerr/txerr counters")
      Link: https://lore.kernel.org/r/20210625130931.27438-4-s.grosjean@peak-system.com
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarStephane Grosjean <s.grosjean@peak-system.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      590eb2b7
    • Zhang Changzhong's avatar
      can: j1939: j1939_xtp_rx_dat_one(): fix rxtimer value between consecutive TP.DT to 750ms · c6eea1c8
      Zhang Changzhong authored
      For receive side, the max time interval between two consecutive TP.DT
      should be 750ms.
      
      Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol")
      Link: https://lore.kernel.org/r/1625569210-47506-1-git-send-email-zhangchangzhong@huawei.com
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
      Acked-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      c6eea1c8
    • Oleksij Rempel's avatar
      can: j1939: j1939_session_deactivate(): clarify lifetime of session object · 0c71437d
      Oleksij Rempel authored
      The j1939_session_deactivate() is decrementing the session ref-count and
      potentially can free() the session. This would cause use-after-free
      situation.
      
      However, the code calling j1939_session_deactivate() does always hold
      another reference to the session, so that it would not be free()ed in
      this code path.
      
      This patch adds a comment to make this clear and a WARN_ON, to ensure
      that future changes will not violate this requirement. Further this
      patch avoids dereferencing the session pointer as a precaution to avoid
      use-after-free if the session is actually free()ed.
      
      Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol")
      Link: https://lore.kernel.org/r/20210714111602.24021-1-o.rempel@pengutronix.deReported-by: default avatarXiaochen Zou <xzou017@ucr.edu>
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      0c71437d
    • Ziyang Xuan's avatar
      can: raw: raw_setsockopt(): fix raw_rcv panic for sock UAF · 54f93336
      Ziyang Xuan authored
      We get a bug during ltp can_filter test as following.
      
      ===========================================
      [60919.264984] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [60919.265223] PGD 8000003dda726067 P4D 8000003dda726067 PUD 3dda727067 PMD 0
      [60919.265443] Oops: 0000 [#1] SMP PTI
      [60919.265550] CPU: 30 PID: 3638365 Comm: can_filter Kdump: loaded Tainted: G        W         4.19.90+ #1
      [60919.266068] RIP: 0010:selinux_socket_sock_rcv_skb+0x3e/0x200
      [60919.293289] RSP: 0018:ffff8d53bfc03cf8 EFLAGS: 00010246
      [60919.307140] RAX: 0000000000000000 RBX: 000000000000001d RCX: 0000000000000007
      [60919.320756] RDX: 0000000000000001 RSI: ffff8d5104a8ed00 RDI: ffff8d53bfc03d30
      [60919.334319] RBP: ffff8d9338056800 R08: ffff8d53bfc29d80 R09: 0000000000000001
      [60919.347969] R10: ffff8d53bfc03ec0 R11: ffffb8526ef47c98 R12: ffff8d53bfc03d30
      [60919.350320] perf: interrupt took too long (3063 > 2500), lowering kernel.perf_event_max_sample_rate to 65000
      [60919.361148] R13: 0000000000000001 R14: ffff8d53bcf90000 R15: 0000000000000000
      [60919.361151] FS:  00007fb78b6b3600(0000) GS:ffff8d53bfc00000(0000) knlGS:0000000000000000
      [60919.400812] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [60919.413730] CR2: 0000000000000010 CR3: 0000003e3f784006 CR4: 00000000007606e0
      [60919.426479] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [60919.439339] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [60919.451608] PKRU: 55555554
      [60919.463622] Call Trace:
      [60919.475617]  <IRQ>
      [60919.487122]  ? update_load_avg+0x89/0x5d0
      [60919.498478]  ? update_load_avg+0x89/0x5d0
      [60919.509822]  ? account_entity_enqueue+0xc5/0xf0
      [60919.520709]  security_sock_rcv_skb+0x2a/0x40
      [60919.531413]  sk_filter_trim_cap+0x47/0x1b0
      [60919.542178]  ? kmem_cache_alloc+0x38/0x1b0
      [60919.552444]  sock_queue_rcv_skb+0x17/0x30
      [60919.562477]  raw_rcv+0x110/0x190 [can_raw]
      [60919.572539]  can_rcv_filter+0xbc/0x1b0 [can]
      [60919.582173]  can_receive+0x6b/0xb0 [can]
      [60919.591595]  can_rcv+0x31/0x70 [can]
      [60919.600783]  __netif_receive_skb_one_core+0x5a/0x80
      [60919.609864]  process_backlog+0x9b/0x150
      [60919.618691]  net_rx_action+0x156/0x400
      [60919.627310]  ? sched_clock_cpu+0xc/0xa0
      [60919.635714]  __do_softirq+0xe8/0x2e9
      [60919.644161]  do_softirq_own_stack+0x2a/0x40
      [60919.652154]  </IRQ>
      [60919.659899]  do_softirq.part.17+0x4f/0x60
      [60919.667475]  __local_bh_enable_ip+0x60/0x70
      [60919.675089]  __dev_queue_xmit+0x539/0x920
      [60919.682267]  ? finish_wait+0x80/0x80
      [60919.689218]  ? finish_wait+0x80/0x80
      [60919.695886]  ? sock_alloc_send_pskb+0x211/0x230
      [60919.702395]  ? can_send+0xe5/0x1f0 [can]
      [60919.708882]  can_send+0xe5/0x1f0 [can]
      [60919.715037]  raw_sendmsg+0x16d/0x268 [can_raw]
      
      It's because raw_setsockopt() concurrently with
      unregister_netdevice_many(). Concurrent scenario as following.
      
      	cpu0						cpu1
      raw_bind
      raw_setsockopt					unregister_netdevice_many
      						unlist_netdevice
      dev_get_by_index				raw_notifier
      raw_enable_filters				......
      can_rx_register
      can_rcv_list_find(..., net->can.rx_alldev_list)
      
      ......
      
      sock_close
      raw_release(sock_a)
      
      ......
      
      can_receive
      can_rcv_filter(net->can.rx_alldev_list, ...)
      raw_rcv(skb, sock_a)
      BUG
      
      After unlist_netdevice(), dev_get_by_index() return NULL in
      raw_setsockopt(). Function raw_enable_filters() will add sock
      and can_filter to net->can.rx_alldev_list. Then the sock is closed.
      Followed by, we sock_sendmsg() to a new vcan device use the same
      can_filter. Protocol stack match the old receiver whose sock has
      been released on net->can.rx_alldev_list in can_rcv_filter().
      Function raw_rcv() uses the freed sock. UAF BUG is triggered.
      
      We can find that the key issue is that net_device has not been
      protected in raw_setsockopt(). Use rtnl_lock to protect net_device
      in raw_setsockopt().
      
      Fixes: c18ce101 ("[CAN]: Add raw protocol")
      Link: https://lore.kernel.org/r/20210722070819.1048263-1-william.xuanziyang@huawei.com
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      54f93336
    • Joakim Zhang's avatar
      arm64: dts: imx8mp: remove fallback compatible string for FlexCAN · f5d156c7
      Joakim Zhang authored
      FlexCAN on i.MX8MP is not derived from i.MX6Q, instead reuses from
      i.MX8QM with extra ECC added and default is enabled, so that the FlexCAN
      would be put into freeze mode without FLEXCAN_QUIRK_DISABLE_MECR quirk.
      
      This patch removes "fsl,imx6q-flexcan" fallback compatible string since
      it's not compatible with the i.MX6Q.
      
      Link: https://lore.kernel.org/r/20210719073437.32078-1-qiangqing.zhang@nxp.comSigned-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Reviewed-by: default avatarFabio Estevam <festevam@gmail.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      f5d156c7
  5. 23 Jul, 2021 13 commits