1. 07 Feb, 2023 1 commit
    • Devid Antonio Filoni's avatar
      can: j1939: do not wait 250 ms if the same addr was already claimed · 4ae5e1e9
      Devid Antonio Filoni authored
      The ISO 11783-5 standard, in "4.5.2 - Address claim requirements", states:
        d) No CF shall begin, or resume, transmission on the network until 250
           ms after it has successfully claimed an address except when
           responding to a request for address-claimed.
      
      But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
      prioritization" show that the CF begins the transmission after 250 ms
      from the first AC (address-claimed) message even if it sends another AC
      message during that time window to resolve the address contention with
      another CF.
      
      As stated in "4.4.2.3 - Address-claimed message":
        In order to successfully claim an address, the CF sending an address
        claimed message shall not receive a contending claim from another CF
        for at least 250 ms.
      
      As stated in "4.4.3.2 - NAME management (NM) message":
        1) A commanding CF can
           d) request that a CF with a specified NAME transmit the address-
              claimed message with its current NAME.
        2) A target CF shall
           d) send an address-claimed message in response to a request for a
              matching NAME
      
      Taking the above arguments into account, the 250 ms wait is requested
      only during network initialization.
      
      Do not restart the timer on AC message if both the NAME and the address
      match and so if the address has already been claimed (timer has expired)
      or the AC message has been sent to resolve the contention with another
      CF (timer is still running).
      Signed-off-by: default avatarDevid Antonio Filoni <devid.filoni@egluetechnologies.com>
      Acked-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Link: https://lore.kernel.org/all/20221125170418.34575-1-devid.filoni@egluetechnologies.com
      Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      4ae5e1e9
  2. 06 Feb, 2023 4 commits
    • Alan Stern's avatar
      net: USB: Fix wrong-direction WARNING in plusb.c · 811d5811
      Alan Stern authored
      The syzbot fuzzer detected a bug in the plusb network driver: A
      zero-length control-OUT transfer was treated as a read instead of a
      write.  In modern kernels this error provokes a WARNING:
      
      usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
      WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411
      usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
      Modules linked in:
      CPU: 1 PID: 4645 Comm: dhcpcd Not tainted
      6.2.0-rc6-syzkaller-00050-g9f266cca #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
      01/12/2023
      RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
      ...
      Call Trace:
       <TASK>
       usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
       usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
       usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
       __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010
       usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068
       pl_vendor_req drivers/net/usb/plusb.c:60 [inline]
       pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]
       pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85
       usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
       __dev_open+0x297/0x4d0 net/core/dev.c:1417
       __dev_change_flags+0x587/0x750 net/core/dev.c:8530
       dev_change_flags+0x97/0x170 net/core/dev.c:8602
       devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147
       inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979
       sock_do_ioctl+0xcc/0x230 net/socket.c:1169
       sock_ioctl+0x1f8/0x680 net/socket.c:1286
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:870 [inline]
       __se_sys_ioctl fs/ioctl.c:856 [inline]
       __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and
      remove the USB_DIR_IN flag.
      
      Reported-and-tested-by: syzbot+2a0e7abd24f1eb90ce25@syzkaller.appspotmail.com
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Fixes: 090ffa9d ("[PATCH] USB: usbnet (9/9) module for pl2301/2302 cables")
      CC: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/00000000000052099f05f3b3e298@google.com/Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      811d5811
    • Casper Andersson's avatar
      net: microchip: sparx5: fix PTP init/deinit not checking all ports · d7d94b26
      Casper Andersson authored
      Check all ports instead of just port_count ports. PTP init was only
      checking ports 0 to port_count. If the hardware ports are not mapped
      starting from 0 then they would be missed, e.g. if only ports 20-30 were
      mapped it would attempt to init ports 0-10, resulting in NULL pointers
      when attempting to timestamp. Now it will init all mapped ports.
      
      Fixes: 70dfe25c ("net: sparx5: Update extraction/injection for timestamping")
      Signed-off-by: default avatarCasper Andersson <casper.casan@gmail.com>
      Reviewed-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7d94b26
    • Herton R. Krzesinski's avatar
      uapi: add missing ip/ipv6 header dependencies for linux/stddef.h · 03702d4d
      Herton R. Krzesinski authored
      Since commit 58e0be1e ("net: use struct_group to copy ip/ipv6
      header addresses"), ip and ipv6 headers started to use the __struct_group
      definition, which is defined at include/uapi/linux/stddef.h. However,
      linux/stddef.h isn't explicitly included in include/uapi/linux/{ip,ipv6}.h,
      which breaks build of xskxceiver bpf selftest if you install the uapi
      headers in the system:
      
      $ make V=1 xskxceiver -C tools/testing/selftests/bpf
      ...
      make: Entering directory '(...)/tools/testing/selftests/bpf'
      gcc -g -O0 -rdynamic -Wall -Werror (...)
      In file included from xskxceiver.c:79:
      /usr/include/linux/ip.h:103:9: error: expected specifier-qualifier-list before ‘__struct_group’
        103 |         __struct_group(/* no tag */, addrs, /* no attrs */,
            |         ^~~~~~~~~~~~~~
      ...
      
      Include the missing <linux/stddef.h> dependency in ip.h and do the
      same for the ipv6.h header.
      
      Fixes: 58e0be1e ("net: use struct_group to copy ip/ipv6 header addresses")
      Signed-off-by: default avatarHerton R. Krzesinski <herton@redhat.com>
      Reviewed-by: default avatarCarlos O'Donell <carlos@redhat.com>
      Tested-by: default avatarCarlos O'Donell <carlos@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03702d4d
    • Julian Anastasov's avatar
      neigh: make sure used and confirmed times are valid · c1d2ecdf
      Julian Anastasov authored
      Entries can linger in cache without timer for days, thanks to
      the gc_thresh1 limit. As result, without traffic, the confirmed
      time can be outdated and to appear to be in the future. Later,
      on traffic, NUD_STALE entries can switch to NUD_DELAY and start
      the timer which can see the invalid confirmed time and wrongly
      switch to NUD_REACHABLE state instead of NUD_PROBE. As result,
      timer is set many days in the future. This is more visible on
      32-bit platforms, with higher HZ value.
      
      Why this is a problem? While we expect unused entries to expire,
      such entries stay in REACHABLE state for too long, locked in
      cache. They are not expired normally, only when cache is full.
      
      Problem and the wrong state change reported by Zhang Changzhong:
      
      172.16.1.18 dev bond0 lladdr 0a:0e:0f:01:12:01 ref 1 used 350521/15994171/350520 probes 4 REACHABLE
      
      350520 seconds have elapsed since this entry was last updated, but it is
      still in the REACHABLE state (base_reachable_time_ms is 30000),
      preventing lladdr from being updated through probe.
      
      Fix it by ensuring timer is started with valid used/confirmed
      times. Considering the valid time range is LONG_MAX jiffies,
      we try not to go too much in the past while we are in
      DELAY/PROBE state. There are also places that need
      used/updated times to be validated while timer is not running.
      Reported-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Tested-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1d2ecdf
  3. 04 Feb, 2023 7 commits
  4. 03 Feb, 2023 1 commit
  5. 02 Feb, 2023 27 commits