1. 30 Mar, 2023 14 commits
  2. 29 Mar, 2023 2 commits
  3. 28 Mar, 2023 15 commits
  4. 27 Mar, 2023 9 commits
    • Ivan Orlov's avatar
      can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write · 2b4c99f7
      Ivan Orlov authored
      Syzkaller reported the following issue:
      
      =====================================================
      BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline]
      BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600
       aio_rw_done fs/aio.c:1520 [inline]
       aio_write+0x899/0x950 fs/aio.c:1600
       io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
       __do_sys_io_submit fs/aio.c:2078 [inline]
       __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
       __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Uninit was created at:
       slab_post_alloc_hook mm/slab.h:766 [inline]
       slab_alloc_node mm/slub.c:3452 [inline]
       __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
       __do_kmalloc_node mm/slab_common.c:967 [inline]
       __kmalloc+0x11d/0x3b0 mm/slab_common.c:981
       kmalloc_array include/linux/slab.h:636 [inline]
       bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930
       bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351
       sock_sendmsg_nosec net/socket.c:714 [inline]
       sock_sendmsg net/socket.c:734 [inline]
       sock_write_iter+0x495/0x5e0 net/socket.c:1108
       call_write_iter include/linux/fs.h:2189 [inline]
       aio_write+0x63a/0x950 fs/aio.c:1600
       io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
       __do_sys_io_submit fs/aio.c:2078 [inline]
       __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
       __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
      =====================================================
      
      We can follow the call chain and find that 'bcm_tx_setup' function
      calls 'memcpy_from_msg' to copy some content to the newly allocated
      frame of 'op->frames'. After that the 'len' field of copied structure
      being compared with some constant value (64 or 8). However, if
      'memcpy_from_msg' returns an error, we will compare some uninitialized
      memory. This triggers 'uninit-value' issue.
      
      This patch will add 'memcpy_from_msg' possible errors processing to
      avoid uninit-value issue.
      
      Tested via syzkaller
      
      Reported-by: syzbot+c9bfd85eca611ebf5db1@syzkaller.appspotmail.com
      Link: https://syzkaller.appspot.com/bug?id=47f897f8ad958bbde5790ebf389b5e7e0a345089Signed-off-by: default avatarIvan Orlov <ivan.orlov0322@gmail.com>
      Fixes: 6f3b911d ("can: bcm: add support for CAN FD frames")
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Link: https://lore.kernel.org/all/20230314120445.12407-1-ivan.orlov0322@gmail.comSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      2b4c99f7
    • Vladimir Oltean's avatar
      net: stmmac: don't reject VLANs when IFF_PROMISC is set · a7602e73
      Vladimir Oltean authored
      The blamed commit has introduced the following tests to
      dwmac4_add_hw_vlan_rx_fltr(), called from stmmac_vlan_rx_add_vid():
      
      	if (hw->promisc) {
      		netdev_err(dev,
      			   "Adding VLAN in promisc mode not supported\n");
      		return -EPERM;
      	}
      
      "VLAN promiscuous" mode is keyed in this driver to IFF_PROMISC, and so,
      vlan_vid_add() and vlan_vid_del() calls cannot take place in IFF_PROMISC
      mode. I have the following 2 arguments that this restriction is.... hm,
      how shall I put it nicely... unproductive :)
      
      First, take the case of a Linux bridge. If the kernel is compiled with
      CONFIG_BRIDGE_VLAN_FILTERING=y, then this bridge shall have a VLAN
      database. The bridge shall try to call vlan_add_vid() on its bridge
      ports for each VLAN in the VLAN table. It will do this irrespectively of
      whether that port is *currently* VLAN-aware or not. So it will do this
      even when the bridge was created with vlan_filtering 0.
      But the Linux bridge, in VLAN-unaware mode, configures its ports in
      promiscuous (IFF_PROMISC) mode, so that they accept packets with any
      MAC DA (a switch must do this in order to forward those packets which
      are not directly targeted to its MAC address).
      
      As a result, the stmmac driver does not work as a bridge port, when the
      kernel is compiled with CONFIG_BRIDGE_VLAN_FILTERING=y.
      
      $ ip link add br0 type bridge && ip link set br0 up
      $ ip link set eth0 master br0 && ip link set eth0 up
      [ 2333.943296] br0: port 1(eth0) entered blocking state
      [ 2333.943381] br0: port 1(eth0) entered disabled state
      [ 2333.943782] device eth0 entered promiscuous mode
      [ 2333.944080] 4033c000.ethernet eth0: Adding VLAN in promisc mode not supported
      [ 2333.976509] 4033c000.ethernet eth0: failed to initialize vlan filtering on this port
      RTNETLINK answers: Operation not permitted
      
      Secondly, take the case of stmmac as DSA master. Some switch tagging
      protocols are based on 802.1Q VLANs (tag_sja1105.c), and as such,
      tag_8021q.c uses vlan_vid_add() to work with VLAN-filtering DSA masters.
      But also, when a DSA port becomes promiscuous (for example when it joins
      a bridge), the DSA framework also makes the DSA master promiscuous.
      
      Moreover, for every VLAN that a DSA switch sends to the CPU, DSA also
      programs a VLAN filter on the DSA master, because if the the DSA switch
      uses a tail tag, then the hardware frame parser of the DSA master will
      see VLAN as VLAN, and might filter them out, for being unknown.
      
      Due to the above 2 reasons, my belief is that the stmmac driver does not
      get to choose to not accept vlan_vid_add() calls while IFF_PROMISC is
      enabled, because the 2 are completely independent and there are code
      paths in the network stack which directly lead to this situation
      occurring, without the user's direct input.
      
      In fact, my belief is that "VLAN promiscuous" mode should have never
      been keyed on IFF_PROMISC in the first place, but rather, on the
      NETIF_F_HW_VLAN_CTAG_FILTER feature flag which can be toggled by the
      user through ethtool -k, when present in netdev->hw_features.
      
      In the stmmac driver, NETIF_F_HW_VLAN_CTAG_FILTER is only present in
      "features", making this feature "on [fixed]".
      
      I have this belief because I am unaware of any definition of promiscuity
      which implies having an effect on anything other than MAC DA (therefore
      not VLAN). However, I seem to be rather alone in having this opinion,
      looking back at the disagreements from this discussion:
      https://lore.kernel.org/netdev/20201110153958.ci5ekor3o2ekg3ky@ipetronik.com/
      
      In any case, to remove the vlan_vid_add() dependency on !IFF_PROMISC,
      one would need to remove the check and see what fails. I guess the test
      was there because of the way in which dwmac4_vlan_promisc_enable() is
      implemented.
      
      For context, the dwmac4 supports Perfect Filtering for a limited number
      of VLANs - dwmac4_get_num_vlan(), priv->hw->num_vlan, with a fallback on
      Hash Filtering - priv->dma_cap.vlhash - see stmmac_vlan_update(), also
      visible in cat /sys/kernel/debug/stmmaceth/eth0/dma_cap | grep 'VLAN
      Hash Filtering'.
      
      The perfect filtering is based on MAC_VLAN_Tag_Filter/MAC_VLAN_Tag_Data
      registers, accessed in the driver through dwmac4_write_vlan_filter().
      
      The hash filtering is based on the MAC_VLAN_Hash_Table register, named
      GMAC_VLAN_HASH_TABLE in the driver and accessed by dwmac4_update_vlan_hash().
      The control bit for enabling hash filtering is GMAC_VLAN_VTHM
      (MAC_VLAN_Tag_Ctrl bit VTHM: VLAN Tag Hash Table Match Enable).
      
      Now, the description of dwmac4_vlan_promisc_enable() is that it iterates
      through the driver's cache of perfect filter entries (hw->vlan_filter[i],
      added by dwmac4_add_hw_vlan_rx_fltr()), and evicts them from hardware by
      unsetting their GMAC_VLAN_TAG_DATA_VEN (MAC_VLAN_Tag_Data bit VEN - VLAN
      Tag Enable) bit. Then it unsets the GMAC_VLAN_VTHM bit, which disables
      hash matching.
      
      This leaves the MAC, according to table "VLAN Match Status" from the
      documentation, to always enter these data paths:
      
      VID    |VLAN Perfect Filter |VTHM Bit |VLAN Hash Filter |Final VLAN Match
             |Match Result        |         |Match Result     |Status
      -------|--------------------|---------|-----------------|----------------
      VID!=0 |Fail                |0        |don't care       |Pass
      
      So, dwmac4_vlan_promisc_enable() does its job, but by unsetting
      GMAC_VLAN_VTHM, it conflicts with the other code path which controls
      this bit: dwmac4_update_vlan_hash(), called through stmmac_update_vlan_hash()
      from stmmac_vlan_rx_add_vid() and from stmmac_vlan_rx_kill_vid().
      This is, I guess, why dwmac4_add_hw_vlan_rx_fltr() is not allowed to run
      after dwmac4_vlan_promisc_enable() has unset GMAC_VLAN_VTHM: because if
      it did, then dwmac4_update_vlan_hash() would set GMAC_VLAN_VTHM again,
      breaking the "VLAN promiscuity".
      
      It turns out that dwmac4_vlan_promisc_enable() is way too complicated
      for what needs to be done. The MAC_Packet_Filter register also has the
      VTFE bit (VLAN Tag Filter Enable), which simply controls whether VLAN
      tagged packets which don't match the filtering tables (either perfect or
      hash) are dropped or not. At the moment, this driver unconditionally
      sets GMAC_PACKET_FILTER_VTFE if NETIF_F_HW_VLAN_CTAG_FILTER was detected
      through the priv->dma_cap.vlhash capability bits of the device, in
      stmmac_dvr_probe().
      
      I would suggest deleting the unnecessarily complex logic from
      dwmac4_vlan_promisc_enable(), and simply unsetting GMAC_PACKET_FILTER_VTFE
      when becoming IFF_PROMISC, which has the same effect of allowing packets
      with any VLAN tags, but has the additional benefit of being able to run
      concurrently with stmmac_vlan_rx_add_vid() and stmmac_vlan_rx_kill_vid().
      
      As much as I believe that the VTFE bit should have been exclusively
      controlled by NETIF_F_HW_VLAN_CTAG_FILTER through ethtool, and not by
      IFF_PROMISC, changing that is not a punctual fix to the problem, and it
      would probably break the VFFQ feature added by the later commit
      e0f9956a ("net: stmmac: Add option for VLAN filter fail queue
      enable"). From the commit description, VFFQ needs IFF_PROMISC=on and
      VTFE=off in order to work (and this change respects that). But if VTFE
      was changed to be controlled through ethtool -k, then a user-visible
      change would have been introduced in Intel's scripts (a need to run
      "ethtool -k eth0 rx-vlan-filter off" which did not exist before).
      
      The patch was tested with this set of commands:
      
        ip link set eth0 up
        ip link add link eth0 name eth0.100 type vlan id 100
        ip addr add 192.168.100.2/24 dev eth0.100 && ip link set eth0.100 up
        ip link set eth0 promisc on
        ip link add link eth0 name eth0.101 type vlan id 101
        ip addr add 192.168.101.2/24 dev eth0.101 && ip link set eth0.101 up
        ip link set eth0 promisc off
        ping -c 5 192.168.100.1
        ping -c 5 192.168.101.1
        ip link set eth0 promisc on
        ping -c 5 192.168.100.1
        ping -c 5 192.168.101.1
        ip link del eth0.100
        ip link del eth0.101
        # Wait for VLAN-tagged pings from the other end...
        # Check with "tcpdump -i eth0 -e -n -p" and we should see them
        ip link set eth0 promisc off
        # Wait for VLAN-tagged pings from the other end...
        # Check with "tcpdump -i eth0 -e -n -p" and we shouldn't see them
        # anymore, but remove the "-p" argument from tcpdump and they're there.
      
      Fixes: c89f44ff ("net: stmmac: Add support for VLAN promiscuous mode")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7602e73
    • Oleksij Rempel's avatar
      can: j1939: prevent deadlock by moving j1939_sk_errqueue() · d1366b28
      Oleksij Rempel authored
      This commit addresses a deadlock situation that can occur in certain
      scenarios, such as when running data TP/ETP transfer and subscribing to
      the error queue while receiving a net down event. The deadlock involves
      locks in the following order:
      
      3
        j1939_session_list_lock ->  active_session_list_lock
        j1939_session_activate
        ...
        j1939_sk_queue_activate_next -> sk_session_queue_lock
        ...
        j1939_xtp_rx_eoma_one
      
      2
        j1939_sk_queue_drop_all  ->  sk_session_queue_lock
        ...
        j1939_sk_netdev_event_netdown -> j1939_socks_lock
        j1939_netdev_notify
      
      1
        j1939_sk_errqueue -> j1939_socks_lock
        __j1939_session_cancel -> active_session_list_lock
        j1939_tp_rxtimer
      
             CPU0                    CPU1
             ----                    ----
        lock(&priv->active_session_list_lock);
                                     lock(&jsk->sk_session_queue_lock);
                                     lock(&priv->active_session_list_lock);
        lock(&priv->j1939_socks_lock);
      
      The solution implemented in this commit is to move the
      j1939_sk_errqueue() call out of the active_session_list_lock context,
      thus preventing the deadlock situation.
      
      Reported-by: syzbot+ee1cd780f69483a8616b@syzkaller.appspotmail.com
      Fixes: 5b9272e9 ("can: j1939: extend UAPI to notify about RX status")
      Co-developed-by: default avatarHillf Danton <hdanton@sina.com>
      Signed-off-by: default avatarHillf Danton <hdanton@sina.com>
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Link: https://lore.kernel.org/all/20230324130141.2132787-1-o.rempel@pengutronix.de
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      d1366b28
    • Álvaro Fernández Rojas's avatar
      net: dsa: b53: mmap: add phy ops · 45977e58
      Álvaro Fernández Rojas authored
      Implement phy_read16() and phy_write16() ops for B53 MMAP to avoid accessing
      B53_PORT_MII_PAGE registers which hangs the device.
      This access should be done through the MDIO Mux bus controller.
      Signed-off-by: default avatarÁlvaro Fernández Rojas <noltari@gmail.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45977e58
    • Oleksij Rempel's avatar
      net: phy: micrel: correct KSZ9131RNX EEE capabilities and advertisement · f2e9d083
      Oleksij Rempel authored
      The KSZ9131RNX incorrectly shows EEE capabilities in its registers.
      Although the "EEE control and capability 1" (Register 3.20) is set to 0,
      indicating no EEE support, the "EEE advertisement 1" (Register 7.60) is
      set to 0x6, advertising EEE support for 1000BaseT/Full and
      100BaseT/Full.
      This inconsistency causes PHYlib to assume there is no EEE support,
      preventing control over EEE advertisement, which is enabled by default.
      
      This patch resolves the issue by utilizing the ksz9477_get_features()
      function to correctly set the EEE capabilities for the KSZ9131RNX. This
      adjustment allows proper control over EEE advertisement and ensures
      accurate representation of the device's capabilities.
      
      Fixes: 8b68710a ("net: phy: start using genphy_c45_ethtool_get/set_eee()")
      Reported-by: default avatarMarek Vasut <marex@denx.de>
      Tested-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2e9d083
    • Stefano Garzarella's avatar
      vsock/loopback: use only sk_buff_head.lock to protect the packet queue · b465518d
      Stefano Garzarella authored
      pkt_list_lock was used before commit 71dc9ec9 ("virtio/vsock:
      replace virtio_vsock_pkt with sk_buff") to protect the packet queue.
      After that commit we switched to sk_buff and we are using
      sk_buff_head.lock in almost every place to protect the packet queue
      except in vsock_loopback_work() when we call skb_queue_splice_init().
      
      As reported by syzbot, this caused unlocked concurrent access to the
      packet queue between vsock_loopback_work() and
      vsock_loopback_cancel_pkt() since it is not holding pkt_list_lock.
      
      With the introduction of sk_buff_head, pkt_list_lock is redundant and
      can cause confusion, so let's remove it and use sk_buff_head.lock
      everywhere to protect the packet queue access.
      
      Fixes: 71dc9ec9 ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
      Cc: bobby.eshleman@bytedance.com
      Reported-and-tested-by: syzbot+befff0a9536049e7902e@syzkaller.appspotmail.com
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Reviewed-by: default avatarBobby Eshleman <bobby.eshleman@bytedance.com>
      Reviewed-by: default avatarArseniy Krasnov <AVKrasnov@sberdevices.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b465518d
    • David S. Miller's avatar
      Merge branch 'constify-sfp-phy-nodes' · 62203584
      David S. Miller authored
      Russell King says:
      
      ====================
      Constify a few sfp/phy fwnodes
      
      This series constifies a bunch of fwnode_handle pointers that are only
      used to refer to but not modify the contents of the fwnode structures.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62203584
    • Russell King (Oracle)'s avatar
      net: phy: constify fwnode_get_phy_node() fwnode argument · 4a0faa02
      Russell King (Oracle) authored
      fwnode_get_phy_node() does not motify the fwnode structure, so make
      the argument const,
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a0faa02
    • Russell King (Oracle)'s avatar
      net: sfp: constify sfp-bus internal fwnode uses · 850a8d2d
      Russell King (Oracle) authored
      Constify sfp-bus internal fwnode uses, since we do not modify the
      fwnode structures.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      850a8d2d