1. 13 Apr, 2022 8 commits
    • Sasha Neftin's avatar
      igc: Fix infinite loop in release_swfw_sync · 907862e9
      Sasha Neftin authored
      An infinite loop may occur if we fail to acquire the HW semaphore,
      which is needed for resource release.
      This will typically happen if the hardware is surprise-removed.
      At this stage there is nothing to do, except log an error and quit.
      
      Fixes: c0071c7a ("igc: Add HW initialization code")
      Suggested-by: default avatarDima Ruinskiy <dima.ruinskiy@intel.com>
      Signed-off-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      907862e9
    • Lin Ma's avatar
      nfc: nci: add flush_workqueue to prevent uaf · ef27324e
      Lin Ma authored
      Our detector found a concurrent use-after-free bug when detaching an
      NCI device. The main reason for this bug is the unexpected scheduling
      between the used delayed mechanism (timer and workqueue).
      
      The race can be demonstrated below:
      
      Thread-1                           Thread-2
                                       | nci_dev_up()
                                       |   nci_open_device()
                                       |     __nci_request(nci_reset_req)
                                       |       nci_send_cmd
                                       |         queue_work(cmd_work)
      nci_unregister_device()          |
        nci_close_device()             | ...
          del_timer_sync(cmd_timer)[1] |
      ...                              | Worker
      nci_free_device()                | nci_cmd_work()
        kfree(ndev)[3]                 |   mod_timer(cmd_timer)[2]
      
      In short, the cleanup routine thought that the cmd_timer has already
      been detached by [1] but the mod_timer can re-attach the timer [2], even
      it is already released [3], resulting in UAF.
      
      This UAF is easy to trigger, crash trace by POC is like below
      
      [   66.703713] ==================================================================
      [   66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490
      [   66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33
      [   66.703974]
      [   66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5
      [   66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work
      [   66.703974] Call Trace:
      [   66.703974]  <TASK>
      [   66.703974]  dump_stack_lvl+0x57/0x7d
      [   66.703974]  print_report.cold+0x5e/0x5db
      [   66.703974]  ? enqueue_timer+0x448/0x490
      [   66.703974]  kasan_report+0xbe/0x1c0
      [   66.703974]  ? enqueue_timer+0x448/0x490
      [   66.703974]  enqueue_timer+0x448/0x490
      [   66.703974]  __mod_timer+0x5e6/0xb80
      [   66.703974]  ? mark_held_locks+0x9e/0xe0
      [   66.703974]  ? try_to_del_timer_sync+0xf0/0xf0
      [   66.703974]  ? lockdep_hardirqs_on_prepare+0x17b/0x410
      [   66.703974]  ? queue_work_on+0x61/0x80
      [   66.703974]  ? lockdep_hardirqs_on+0xbf/0x130
      [   66.703974]  process_one_work+0x8bb/0x1510
      [   66.703974]  ? lockdep_hardirqs_on_prepare+0x410/0x410
      [   66.703974]  ? pwq_dec_nr_in_flight+0x230/0x230
      [   66.703974]  ? rwlock_bug.part.0+0x90/0x90
      [   66.703974]  ? _raw_spin_lock_irq+0x41/0x50
      [   66.703974]  worker_thread+0x575/0x1190
      [   66.703974]  ? process_one_work+0x1510/0x1510
      [   66.703974]  kthread+0x2a0/0x340
      [   66.703974]  ? kthread_complete_and_exit+0x20/0x20
      [   66.703974]  ret_from_fork+0x22/0x30
      [   66.703974]  </TASK>
      [   66.703974]
      [   66.703974] Allocated by task 267:
      [   66.703974]  kasan_save_stack+0x1e/0x40
      [   66.703974]  __kasan_kmalloc+0x81/0xa0
      [   66.703974]  nci_allocate_device+0xd3/0x390
      [   66.703974]  nfcmrvl_nci_register_dev+0x183/0x2c0
      [   66.703974]  nfcmrvl_nci_uart_open+0xf2/0x1dd
      [   66.703974]  nci_uart_tty_ioctl+0x2c3/0x4a0
      [   66.703974]  tty_ioctl+0x764/0x1310
      [   66.703974]  __x64_sys_ioctl+0x122/0x190
      [   66.703974]  do_syscall_64+0x3b/0x90
      [   66.703974]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [   66.703974]
      [   66.703974] Freed by task 406:
      [   66.703974]  kasan_save_stack+0x1e/0x40
      [   66.703974]  kasan_set_track+0x21/0x30
      [   66.703974]  kasan_set_free_info+0x20/0x30
      [   66.703974]  __kasan_slab_free+0x108/0x170
      [   66.703974]  kfree+0xb0/0x330
      [   66.703974]  nfcmrvl_nci_unregister_dev+0x90/0xd0
      [   66.703974]  nci_uart_tty_close+0xdf/0x180
      [   66.703974]  tty_ldisc_kill+0x73/0x110
      [   66.703974]  tty_ldisc_hangup+0x281/0x5b0
      [   66.703974]  __tty_hangup.part.0+0x431/0x890
      [   66.703974]  tty_release+0x3a8/0xc80
      [   66.703974]  __fput+0x1f0/0x8c0
      [   66.703974]  task_work_run+0xc9/0x170
      [   66.703974]  exit_to_user_mode_prepare+0x194/0x1a0
      [   66.703974]  syscall_exit_to_user_mode+0x19/0x50
      [   66.703974]  do_syscall_64+0x48/0x90
      [   66.703974]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      To fix the UAF, this patch adds flush_workqueue() to ensure the
      nci_cmd_work is finished before the following del_timer_sync.
      This combination will promise the timer is actually detached.
      
      Fixes: 6a2968aa ("NFC: basic NCI protocol implementation")
      Signed-off-by: default avatarLin Ma <linma@zju.edu.cn>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef27324e
    • Alvin Šipraga's avatar
      net: dsa: realtek: don't parse compatible string for RTL8366S · 8e925de6
      Alvin Šipraga authored
      This switch is not even supported, but if someone were to actually put
      this compatible string "realtek,rtl8366s" in their device tree, they
      would be greeted with a kernel panic because the probe function would
      dereference NULL. So let's just remove it.
      
      Link: https://lore.kernel.org/all/CACRpkdYdKZs0WExXc3=0yPNOwP+oOV60HRz7SRoGjZvYHaT=1g@mail.gmail.com/Signed-off-by: default avatarAlvin Šipraga <alsi@bang-olufsen.dk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e925de6
    • Alvin Šipraga's avatar
      net: dsa: realtek: fix Kconfig to assure consistent driver linkage · 2511e0c8
      Alvin Šipraga authored
      The kernel test robot reported a build failure:
      
      or1k-linux-ld: drivers/net/dsa/realtek/realtek-smi.o:(.rodata+0x16c): undefined reference to `rtl8366rb_variant'
      
      ... with the following build configuration:
      
      CONFIG_NET_DSA_REALTEK=y
      CONFIG_NET_DSA_REALTEK_SMI=y
      CONFIG_NET_DSA_REALTEK_RTL8365MB=y
      CONFIG_NET_DSA_REALTEK_RTL8366RB=m
      
      The problem here is that the realtek-smi interface driver gets built-in,
      while the rtl8366rb switch subdriver gets built as a module, hence the
      symbol rtl8366rb_variant is not reachable when defining the OF device
      table in the interface driver.
      
      The Kconfig dependencies don't help in this scenario because they just
      say that the subdriver(s) depend on at least one interface driver. In
      fact, the subdrivers don't depend on the interface drivers at all, and
      can even be built even in their absence. Somewhat strangely, the
      interface drivers can also be built in the absence of any subdriver,
      BUT, if a subdriver IS enabled, then it must be reachable according to
      the linkage of the interface driver: effectively what the IS_REACHABLE()
      macro achieves. If it is not reachable, the above kind of linker error
      will be observed.
      
      Rather than papering over the above build error by simply using
      IS_REACHABLE(), we can do a little better and admit that it is actually
      the interface drivers that have a dependency on the subdrivers. So this
      patch does exactly that. Specifically, we ensure that:
      
      1. The interface drivers' Kconfig symbols must have a value no greater
         than the value of any subdriver Kconfig symbols.
      
      2. The subdrivers should by default enable both interface drivers, since
         most users probably want at least one of them; those interface
         drivers can be explicitly disabled however.
      
      What this doesn't do is prevent a user from building only a subdriver,
      without any interface driver. To that end, add an additional line of
      help in the menu to guide users in the right direction.
      
      Link: https://lore.kernel.org/all/202204110757.XIafvVnj-lkp@intel.com/Reported-by: default avatarkernel test robot <lkp@intel.com>
      Fixes: aac94001 ("net: dsa: realtek: add new mdio interface for drivers")
      Signed-off-by: default avatarAlvin Šipraga <alsi@bang-olufsen.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2511e0c8
    • David S. Miller's avatar
      Merge tag 'wireless-2022-04-13' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless · dad32cfe
      David S. Miller authored
      Kalle Valo says:
      
      ====================
      wireless fixes for v5.18
      
      First set of fixes for v5.18. Maintainers file updates, two
      compilation warning fixes, one revert for ath11k and smaller fixes to
      drivers and stack. All the usual stuff.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dad32cfe
    • Dylan Hung's avatar
      net: ftgmac100: access hardware register after clock ready · 3d250452
      Dylan Hung authored
      AST2600 MAC register 0x58 is writable only when the MAC clock is
      enabled.  Usually, the MAC clock is enabled by the bootloader so
      register 0x58 is set normally when the bootloader is involved.  To make
      ast2600 ftgmac100 work without the bootloader, postpone the register
      write until the clock is ready.
      
      Fixes: 137d23ce ("net: ftgmac100: Fix Aspeed ast2600 TX hang issue")
      Signed-off-by: default avatarDylan Hung <dylan_hung@aspeedtech.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d250452
    • Vladimir Oltean's avatar
      Revert "net: dsa: setup master before ports" · 762c2998
      Vladimir Oltean authored
      This reverts commit 11fd667d.
      
      dsa_slave_change_mtu() updates the MTU of the DSA master and of the
      associated CPU port, but only if it detects a change to the master MTU.
      
      The blamed commit in the Fixes: tag below addressed a regression where
      dsa_slave_change_mtu() would return early and not do anything due to
      ds->ops->port_change_mtu() not being implemented.
      
      However, that commit also had the effect that the master MTU got set up
      to the correct value by dsa_master_setup(), but the associated CPU port's
      MTU did not get updated. This causes breakage for drivers that rely on
      the ->port_change_mtu() DSA call to account for the tagging overhead on
      the CPU port, and don't set up the initial MTU during the setup phase.
      
      Things actually worked before because they were in a fragile equilibrium
      where dsa_slave_change_mtu() was called before dsa_master_setup() was.
      So dsa_slave_change_mtu() could actually detect a change and update the
      CPU port MTU too.
      
      Restore the code to the way things used to work by reverting the reorder
      of dsa_tree_setup_master() and dsa_tree_setup_ports(). That change did
      not have a concrete motivation going for it anyway, it just looked
      better.
      
      Fixes: 066dfc42 ("Revert "net: dsa: stop updating master MTU from master.c"")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      762c2998
    • Martin Willi's avatar
      macvlan: Fix leaking skb in source mode with nodst option · e16b8598
      Martin Willi authored
      The MACVLAN receive handler clones skbs to all matching source MACVLAN
      interfaces, before it passes the packet along to match on destination
      based MACVLANs.
      
      When using the MACVLAN nodst mode, passing the packet to destination based
      MACVLANs is omitted and the handler returns with RX_HANDLER_CONSUMED.
      However, the passed skb is not freed, leaking for any packet processed
      with the nodst option.
      
      Properly free the skb when consuming packets to fix that leak.
      
      Fixes: 427f0c8c ("macvlan: Add nodst option to macvlan type source")
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e16b8598
  2. 12 Apr, 2022 14 commits
  3. 11 Apr, 2022 9 commits
  4. 10 Apr, 2022 3 commits
  5. 09 Apr, 2022 2 commits
  6. 08 Apr, 2022 4 commits