1. 14 Aug, 2020 8 commits
  2. 20 Jul, 2020 2 commits
    • Zekun Shen's avatar
      ath10k: check idx validity in __ath10k_htt_rx_ring_fill_n() · bad60b8d
      Zekun Shen authored
      The idx in __ath10k_htt_rx_ring_fill_n function lives in
      consistent dma region writable by the device. Malfunctional
      or malicious device could manipulate such idx to have a OOB
      write. Either by
          htt->rx_ring.netbufs_ring[idx] = skb;
      or by
          ath10k_htt_set_paddrs_ring(htt, paddr, idx);
      
      The idx can also be negative as it's signed, giving a large
      memory space to write to.
      
      It's possibly exploitable by corruptting a legit pointer with
      a skb pointer. And then fill skb with payload as rougue object.
      
      Part of the log here. Sometimes it appears as UAF when writing
      to a freed memory by chance.
      
       [   15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0
       [   15.595483] #PF: supervisor write access in kernel mode
       [   15.596250] #PF: error_code(0x0002) - not-present page
       [   15.597013] PGD 0 P4D 0
       [   15.597395] Oops: 0002 [#1] SMP KASAN PTI
       [   15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69
       [   15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
       BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
       [   15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
       [   15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n
       (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core
      Signed-off-by: default avatarZekun Shen <bruceshenzk@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200623221105.3486-1-bruceshenzk@gmail.com
      bad60b8d
    • Bolarinwa Olayemi Saheed's avatar
      ath9k: Check the return value of pcie_capability_read_*() · 9a8ab2bf
      Bolarinwa Olayemi Saheed authored
      On failure pcie_capability_read_dword() sets it's last parameter, val
      to 0. However, with Patch 14/14, it is possible that val is set to ~0 on
      failure. This would introduce a bug because (x & x) == (~0 & x).
      
      This bug can be avoided without changing the function's behaviour if the
      return value of pcie_capability_read_dword is checked to confirm success.
      
      Check the return value of pcie_capability_read_dword() to ensure success.
      Suggested-by: default avatarBjorn Helgaas <bjorn@helgaas.com>
      Signed-off-by: default avatarBolarinwa Olayemi Saheed <refactormyself@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200713175529.29715-2-refactormyself@gmail.com
      9a8ab2bf
  3. 23 Jun, 2020 13 commits
  4. 16 Jun, 2020 6 commits
  5. 15 Jun, 2020 8 commits
  6. 14 Jun, 2020 3 commits