1. 17 May, 2023 12 commits
    • Vladimir Oltean's avatar
      net: pcs: xpcs: fix C73 AN not getting enabled · c46e78ba
      Vladimir Oltean authored
      The XPCS expects clause 73 (copper backplane) autoneg to follow the
      ethtool autoneg bit. It actually did that until the blamed
      commit inaptly replaced state->an_enabled (coming from ethtool) with
      phylink_autoneg_inband() (coming from the device tree or struct
      phylink_config), as part of an unrelated phylink_pcs API conversion.
      
      Russell King suggests that state->an_enabled from the original code was
      just a proxy for the ethtool Autoneg bit, and that the correct way of
      restoring the functionality is to check for this bit in the advertising
      mask.
      
      Fixes: 11059740 ("net: pcs: xpcs: convert to phylink_pcs_ops")
      Link: https://lore.kernel.org/netdev/ZGNt2MFeRolKGFck@shell.armlinux.org.uk/Suggested-by: default avatarRussell King (Oracle) <linux@armlinux.org.uk>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c46e78ba
    • M Chetan Kumar's avatar
      net: wwan: iosm: fix NULL pointer dereference when removing device · 60829145
      M Chetan Kumar authored
      In suspend and resume cycle, the removal and rescan of device ends
      up in NULL pointer dereference.
      
      During driver initialization, if the ipc_imem_wwan_channel_init()
      fails to get the valid device capabilities it returns an error and
      further no resource (wwan struct) will be allocated. Now in this
      situation if driver removal procedure is initiated it would result
      in NULL pointer exception since unallocated wwan struct is dereferenced
      inside ipc_wwan_deinit().
      
      ipc_imem_run_state_worker() to handle the called functions return value
      and to release the resource in failure case. It also reports the link
      down event in failure cases. The user space application can handle this
      event to do a device reset for restoring the device communication.
      
      Fixes: 3670970d ("net: iosm: shared memory IPC interface")
      Reported-by: default avatarSamuel Wein PhD <sam@samwein.com>
      Closes: https://lore.kernel.org/netdev/20230427140819.1310f4bd@kernel.org/T/Signed-off-by: default avatarM Chetan Kumar <m.chetan.kumar@linux.intel.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60829145
    • Eric Dumazet's avatar
      vlan: fix a potential uninit-value in vlan_dev_hard_start_xmit() · dacab578
      Eric Dumazet authored
      syzbot triggered the following splat [1], sending an empty message
      through pppoe_sendmsg().
      
      When VLAN_FLAG_REORDER_HDR flag is set, vlan_dev_hard_header()
      does not push extra bytes for the VLAN header, because vlan is offloaded.
      
      Unfortunately vlan_dev_hard_start_xmit() first reads veth->h_vlan_proto
      before testing (vlan->flags & VLAN_FLAG_REORDER_HDR).
      
      We need to swap the two conditions.
      
      [1]
      BUG: KMSAN: uninit-value in vlan_dev_hard_start_xmit+0x171/0x7f0 net/8021q/vlan_dev.c:111
      vlan_dev_hard_start_xmit+0x171/0x7f0 net/8021q/vlan_dev.c:111
      __netdev_start_xmit include/linux/netdevice.h:4883 [inline]
      netdev_start_xmit include/linux/netdevice.h:4897 [inline]
      xmit_one net/core/dev.c:3580 [inline]
      dev_hard_start_xmit+0x253/0xa20 net/core/dev.c:3596
      __dev_queue_xmit+0x3c7f/0x5ac0 net/core/dev.c:4246
      dev_queue_xmit include/linux/netdevice.h:3053 [inline]
      pppoe_sendmsg+0xa93/0xb80 drivers/net/ppp/pppoe.c:900
      sock_sendmsg_nosec net/socket.c:724 [inline]
      sock_sendmsg net/socket.c:747 [inline]
      ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501
      ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555
      __sys_sendmmsg+0x411/0xa50 net/socket.c:2641
      __do_sys_sendmmsg net/socket.c:2670 [inline]
      __se_sys_sendmmsg net/socket.c:2667 [inline]
      __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2667
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Uninit was created at:
      slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:774
      slab_alloc_node mm/slub.c:3452 [inline]
      kmem_cache_alloc_node+0x543/0xab0 mm/slub.c:3497
      kmalloc_reserve+0x148/0x470 net/core/skbuff.c:520
      __alloc_skb+0x3a7/0x850 net/core/skbuff.c:606
      alloc_skb include/linux/skbuff.h:1277 [inline]
      sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2583
      pppoe_sendmsg+0x3af/0xb80 drivers/net/ppp/pppoe.c:867
      sock_sendmsg_nosec net/socket.c:724 [inline]
      sock_sendmsg net/socket.c:747 [inline]
      ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501
      ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555
      __sys_sendmmsg+0x411/0xa50 net/socket.c:2641
      __do_sys_sendmmsg net/socket.c:2670 [inline]
      __se_sys_sendmmsg net/socket.c:2667 [inline]
      __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2667
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      CPU: 0 PID: 29770 Comm: syz-executor.0 Not tainted 6.3.0-rc6-syzkaller-gc478e5b17829 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dacab578
    • Nikolay Aleksandrov's avatar
      mailmap: add entries for Nikolay Aleksandrov · 66353baf
      Nikolay Aleksandrov authored
      Turns out I missed a few patches due to use of old addresses by
      senders. Add a mailmap entry with my old addresses.
      Signed-off-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66353baf
    • Aleksandr Loktionov's avatar
      igb: fix bit_shift to be in [1..8] range · 60d75865
      Aleksandr Loktionov authored
      In igb_hash_mc_addr() the expression:
              "mc_addr[4] >> 8 - bit_shift", right shifting "mc_addr[4]"
      shift by more than 7 bits always yields zero, so hash becomes not so different.
      Add initialization with bit_shift = 1 and add a loop condition to ensure
      bit_shift will be always in [1..8] range.
      
      Fixes: 9d5c8243 ("igb: PCI-Express 82575 Gigabit Ethernet driver")
      Signed-off-by: default avatarAleksandr Loktionov <aleksandr.loktionov@intel.com>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60d75865
    • David S. Miller's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · 5ad3bd84
      David S. Miller authored
      Tony nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2023-05-16
      
      This series contains updates to ice and iavf drivers.
      
      Ahmed adds setting of missed condition for statistics which caused
      incorrect reporting of values for ice. For iavf, he removes a call to set
      VLAN offloads during re-initialization which can cause incorrect values
      to be set.
      
      Dawid adds checks to ensure VF is ready to be reset before executing
      commands that will require it to be reset on ice.
      ---
      v2:
      Patch 2
      - Redo commit message
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ad3bd84
    • Marco Migliore's avatar
      net: dsa: mv88e6xxx: Fix mv88e6393x EPC write command offset · 1323e0c6
      Marco Migliore authored
      According to datasheet, the command opcode must be specified
      into bits [14:12] of the Extended Port Control register (EPC).
      
      Fixes: de776d0d ("net: dsa: mv88e6xxx: add support for mv88e6393x family")
      Signed-off-by: default avatarMarco Migliore <m.migliore@tiesse.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1323e0c6
    • Christophe JAILLET's avatar
      cassini: Fix a memory leak in the error handling path of cas_init_one() · 412cd77a
      Christophe JAILLET authored
      cas_saturn_firmware_init() allocates some memory using vmalloc(). This
      memory is freed in the .remove() function but not it the error handling
      path of the probe.
      
      Add the missing vfree() to avoid a memory leak, should an error occur.
      
      Fixes: fcaa4066 ("cassini: use request_firmware")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Reviewed-by: default avatarPavan Chebbi <pavan.chebbi@broadcom.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      412cd77a
    • Kuniyuki Iwashima's avatar
      tun: Fix memory leak for detached NAPI queue. · 82b2bc27
      Kuniyuki Iwashima authored
      syzkaller reported [0] memory leaks of sk and skb related to the TUN
      device with no repro, but we can reproduce it easily with:
      
        struct ifreq ifr = {}
        int fd_tun, fd_tmp;
        char buf[4] = {};
      
        fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0);
        ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE;
        ioctl(fd_tun, TUNSETIFF, &ifr);
      
        ifr.ifr_flags = IFF_DETACH_QUEUE;
        ioctl(fd_tun, TUNSETQUEUE, &ifr);
      
        fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0);
        ifr.ifr_flags = IFF_UP;
        ioctl(fd_tmp, SIOCSIFFLAGS, &ifr);
      
        write(fd_tun, buf, sizeof(buf));
        close(fd_tun);
      
      If we enable NAPI and multi-queue on a TUN device, we can put skb into
      tfile->sk.sk_write_queue after the queue is detached.  We should prevent
      it by checking tfile->detached before queuing skb.
      
      Note this must be done under tfile->sk.sk_write_queue.lock because write()
      and ioctl(IFF_DETACH_QUEUE) can run concurrently.  Otherwise, there would
      be a small race window:
      
        write()                             ioctl(IFF_DETACH_QUEUE)
        `- tun_get_user                     `- __tun_detach
           |- if (tfile->detached)             |- tun_disable_queue
           |  `-> false                        |  `- tfile->detached = tun
           |                                   `- tun_queue_purge
           |- spin_lock_bh(&queue->lock)
           `- __skb_queue_tail(queue, skb)
      
      Another solution is to call tun_queue_purge() when closing and
      reattaching the detached queue, but it could paper over another
      problems.  Also, we do the same kind of test for IFF_NAPI_FRAGS.
      
      [0]:
      unreferenced object 0xffff88801edbc800 (size 2048):
        comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
        backtrace:
          [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline]
          [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979
          [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline]
          [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035
          [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088
          [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438
          [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165
          [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414
          [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920
          [<000000008eb24774>] do_open fs/namei.c:3636 [inline]
          [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791
          [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818
          [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356
          [<00000000057be699>] do_sys_open fs/open.c:1372 [inline]
          [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline]
          [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline]
          [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383
          [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
          [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80
          [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
      unreferenced object 0xffff88802f671700 (size 240):
        comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s)
        hex dump (first 32 bytes):
          68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff  h.......h.......
          00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff  ..{/............
        backtrace:
          [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644
          [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline]
          [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378
          [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729
          [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline]
          [<00000000e9eb3df3>] tun_get_user+0x5e1/0x1f90 drivers/net/tun.c:1841
          [<0000000053096912>] tun_chr_write_iter+0xac/0x120 drivers/net/tun.c:2035
          [<00000000b9282ae0>] call_write_iter include/linux/fs.h:1868 [inline]
          [<00000000b9282ae0>] new_sync_write fs/read_write.c:491 [inline]
          [<00000000b9282ae0>] vfs_write+0x40f/0x530 fs/read_write.c:584
          [<00000000524566e4>] ksys_write+0xa1/0x170 fs/read_write.c:637
          [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
          [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80
          [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
      Fixes: cde8b15f ("tuntap: add ioctl to attach or detach a file form tuntap device")
      Reported-by: default avatarsyzkaller <syzkaller@googlegroups.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82b2bc27
    • Jakub Kicinski's avatar
      Merge tag 'ipsec-2023-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · 6ad85ed0
      Jakub Kicinski authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2023-05-16
      
      1) Don't check the policy default if we have an allow
         policy. Fix from Sabrina Dubroca.
      
      2) Fix netdevice refount usage on offload.
         From Leon Romanovsky.
      
      3) Use netdev_put instead of dev_puti to correctly release
         the netdev on failure in xfrm_dev_policy_add.
         From Leon Romanovsky.
      
      4) Revert "Fix XFRM-I support for nested ESP tunnels"
         This broke Netfilter policy matching.
         From Martin Willi.
      
      5) Reject optional tunnel/BEET mode templates in outbound policies
         on netlink and pfkey sockets. From Tobias Brunner.
      
      6) Check if_id in inbound policy/secpath match to make
         it symetric to the outbound codepath.
         From Benedict Wong.
      
      * tag 'ipsec-2023-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:
        xfrm: Check if_id in inbound policy/secpath match
        af_key: Reject optional tunnel/BEET mode templates in outbound policies
        xfrm: Reject optional tunnel/BEET mode templates in outbound policies
        Revert "Fix XFRM-I support for nested ESP tunnels"
        xfrm: Fix leak of dev tracker
        xfrm: release all offloaded policy memory
        xfrm: don't check the default policy if the policy allows the packet
      ====================
      
      Link: https://lore.kernel.org/r/20230516052405.2677554-1-steffen.klassert@secunet.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6ad85ed0
    • Jakub Kicinski's avatar
      Merge tag 'linux-can-fixes-for-6.4-20230515' of... · 47d55c62
      Jakub Kicinski authored
      Merge tag 'linux-can-fixes-for-6.4-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2023-05-15
      
      The first 2 patches are by Oliver Hartkopp and allow the
      MSG_CMSG_COMPAT flag for isotp and j1939.
      
      The next patch is by Oliver Hartkopp, too and adds missing CAN XL
      support in can_put_echo_skb().
      
      Geert Uytterhoeven's patch let's the bxcan driver depend on
      ARCH_STM32.
      
      The last 5 patches are from Dario Binacchi and also affect the bxcan
      driver. The bxcan driver hit mainline with v6.4-rc1 and was originally
      written for IP cores containing 2 CAN interfaces with shared
      resources. Dario's series updates the DT bindings and driver to
      support IP cores with a single CAN interface instance as well as
      adding the bxcan to the stm32f746's device tree.
      
      * tag 'linux-can-fixes-for-6.4-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
        ARM: dts: stm32: add CAN support on stm32f746
        can: bxcan: add support for single peripheral configuration
        ARM: dts: stm32: add pin map for CAN controller on stm32f7
        ARM: dts: stm32f429: put can2 in secondary mode
        dt-bindings: net: can: add "st,can-secondary" property
        can: CAN_BXCAN should depend on ARCH_STM32
        can: dev: fix missing CAN XL support in can_put_echo_skb()
        can: j1939: recvmsg(): allow MSG_CMSG_COMPAT flag
        can: isotp: recvmsg(): allow MSG_CMSG_COMPAT flag
      ====================
      
      Link: https://lore.kernel.org/r/20230515204722.1000957-1-mkl@pengutronix.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      47d55c62
    • Ido Schimmel's avatar
      devlink: Fix crash with CONFIG_NET_NS=n · d6352dae
      Ido Schimmel authored
      '__net_initdata' becomes a no-op with CONFIG_NET_NS=y, but when this
      option is disabled it becomes '__initdata', which means the data can be
      freed after the initialization phase. This annotation is obviously
      incorrect for the devlink net device notifier block which is still
      registered after the initialization phase [1].
      
      Fix this crash by removing the '__net_initdata' annotation.
      
      [1]
      general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] PREEMPT SMP
      CPU: 3 PID: 117 Comm: (udev-worker) Not tainted 6.4.0-rc1-custom-gdf0acdc5 #64
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014
      RIP: 0010:notifier_call_chain+0x58/0xc0
      [...]
      Call Trace:
       <TASK>
       dev_set_mac_address+0x85/0x120
       dev_set_mac_address_user+0x30/0x50
       do_setlink+0x219/0x1270
       rtnl_setlink+0xf7/0x1a0
       rtnetlink_rcv_msg+0x142/0x390
       netlink_rcv_skb+0x58/0x100
       netlink_unicast+0x188/0x270
       netlink_sendmsg+0x214/0x470
       __sys_sendto+0x12f/0x1a0
       __x64_sys_sendto+0x24/0x30
       do_syscall_64+0x38/0x80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Fixes: e93c9378 ("devlink: change per-devlink netdev notifier to static one")
      Reported-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Closes: https://lore.kernel.org/netdev/600ddf9e-589a-2aa0-7b69-a438f833ca10@samsung.com/Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Link: https://lore.kernel.org/r/20230515162925.1144416-1-idosch@nvidia.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d6352dae
  2. 16 May, 2023 4 commits
  3. 15 May, 2023 19 commits
  4. 13 May, 2023 5 commits